Revenue management
Last updated
Was this helpful?
Last updated
Was this helpful?
A Revenue Management System (RMS) optimizes occupancy and rates to achieve maximum total revenue for a property. To do this, a Revenue management integration fetches information about reservations, revenue and pricing from Mews, and then based on this data may recommend new rates, or directly update the rates, and estimates future revenue and occupancy. In bigger properties, there may be more than 50,000 reservations in a year, so it is necessary to limit operations in terms of potential data size, in order to avoid timeouts, network errors, etc. A recommended approach for implementing a Revenue management integration is described below. Following these guidelines should ensure that both our servers and those of the RMS are not unnecessarily overburdened.
Data export: See also below.
An initial data pull is performed once when setting up the connection, because the RMS needs to obtain historical data on which to base its calculations.
The RMS should fetch the reservations in time-limited batches using , with set to Start. That will give you all reservations with an arrival time colliding with the selected interval. The optimum size of the batches depends on the size of the property and its occupancy, but in general weekly batches are recommended and will work well even for big hotels of 1000+ units. For example, in order to get reservations for the past year, the RMS should call sequentially 52 times, with one call for each week in the past year. That would give the RMS all reservations that have an arrival within the past year.
'How to' use case
API Operations
How to get historical reservations data
You can take advantage of the fact that reservations are usually booked a few weeks or months in advance. The further in future, the lower the occupancy, so the reservation batch length may increase with the distance to future from the current date. For example, weekly batches can be used only for the first three months of the future year when there is higher occupancy. And for the remaining 9 months, monthly batches would be sufficient. This will reduce the operation count from 52 to 21 (12 weekly batches + 9 monthly batches).
The RMS can also pull business segments via and rates via . To obtain revenue items associated with reservations, use . Information about resource blocks, e.g. rooms out of order, can be requested using . If you are managing availability blocks, see the use case for information on relevant operations.
'How to' use case
API Operations
How to get all configured business segments
How to get all configured rates and rate groups
How to get order items linked to a reservation
How to get information about out-of-order blocks
It is important to get the reservations and revenue first and the additional data afterwards. If done the other way around, there is a possibility that the RMS receives a reservation with a RateId which does not correspond to any rate that was pulled beforehand. Rates and business segments are dynamic and hotel employees could create a new one and assign it to a reservation just before the reservation gets pulled to the RMS.
'How to' use case
API Operations
How to create a bulk data export
How to check on data export progress
The suggested frequency for periodic reservation syncing is 30 minutes for business intelligence solutions. Adjust the frequency depending on your use case. For example, a mobile key integration would rely more on real-time accuracy of reservation data to provide correct door access to the guest, whereas a thirty-minute to one-hour (or longer) interval period might suffice for a business intelligence solution aimed at providing daily statistical insight to a property's business operations.
'How to' use case
API Operations
How to listen for changes to reservations
How to get reservation details
'How to' use case
API Operations
How to get all configured rates
How to get all configured rate groups
How to get the price for a specific rate and time period
How to listen for changes to rate prices
'How to' use case
API Operations
How to get service restrictions
How to add service restrictions
How to remove service restrictions
When calculating occupancy, it is important to take the hierarchy of resources into account. For example, if there is a reservation against a dormitory (or dorm), then not only is the dormitory occupied but also the beds which are child resources of the dormitory. And vice versa, if a bed in a dorm is occupied, then the dorm is also occupied.
For testing Webhooks or WebSockets, set up your system to start listening for events, then manually trigger an event, e.g. update any element within a reservation.
Help Guides:
Terminology: For an explanation of terms such as business segment, see the .
As an alternative to making conventional API requests using , we provide a bulk feature.
To keep reservations up-to-date and synced across your systems in real time, first cache the reservation data retrieved from the initial reservation data pull, then use (ServiceOrderUpdated event) or (Reservation event) to listen for reservation events. When you receive a reservation event, use the reservation Id obtained from the event to fetch the details of the reservation with .
WebSocket disconnection: In case of WebSocket disconnection, use with UpdatedUtc to perform a full resync of reservations that have been updated within the time period since the last full reservation data pull.
(ServiceOrderUpdated event) or (Reservation event)
To get rate information, there are three relevant operations. gives you information about the names and IDs of the rates in the property, and their status, and also restrictions. gives you information rate groups. And gives you the pricing of a specific rate for a specific time period. In order to update rate prices, use . Individual rate, resource category and time span can be selected. To avoid heavy consumption of API resources, while keeping rate price data up-to-date in real time, use to listen for PriceUpdate events. Then retrieve information about the relevant rates using , filtering by the relevant RateId.
(PriceUpdate event)
To retrieve information about restrictions, use . To add and remove restrictions, use and respectively.
Important: For more information about restrictions, including the algorithms used when setting and clearing restrictions, and the scope of restrictions affected by API operations, see .
Once your integration is completed, all operations should be tested prior to initiating the with the Mews Marketplace team. Testing your solution is done directly in the Connector API Demo environment. You should use the credentials found in to sign in as an end-user. This allows you to understand how both your system and the Mews system will be used by the property and gives you additional information to ensure you can provide a seamless on-boarding experience for our customers.
For help on how to create new reservations, please follow the steps outlined in the guide. If you'd like to double-check that you are correctly requesting all the reservations you want to retrieve, you can compare the API response to the Mews . This report can easily be exported in various formats following the steps in .