What is i-Rates anyway? How I can benefit from it? Is it “yet-another-data-view” software, or does it have something brand-new inside? This document is organized as a Q&A dialogue between a Revenue Management expert and an i-Rates specialist. If you found some important questions unanswered, please feel free to contact us.
- Is i-Rates simply Revenue Management software, or a Pricing and Revenue Management Optimization system?
There’s a difference between Revenue Management software and Pricing and Revenue Management systems. Revenue Management software is more narrowly defined. Pricing and Revenue management/revenue optimization software pulls on historical and current trends, current business analysis, rate plans, availability and local market information. It is designed to strategically suggest pricing, and not just to go to a higher or lower price.
This difference in the intelligence of the systems is meaningful! We developed an innovative Pricing and Revenue optimization control system, which also includes traditional diagnostic/monitoring features. General data monitoring plays a secondary role, and its function is to support optimal strategic control decisions. The latter is the key.
- How do you describe the synthesis of a managers’ expertise and innovative computer intelligence implemented in your system?
i-Rates is the first computer system that provides a combination of a manager’s expertise, efficient information about demand level, market conditions, and innovative mathematical methods of Reinforcement Learning. Thus coupling human intelligence with computer intelligence. This provides an unequaled method of solving daily tasks and making decisions in pricing and revenue management.
More precisely, the computer-aided intelligence of i-Rates is the fusion of machine algorithms for the analysis of dynamics, and human experience in the qualifying of the actual sales state.
It is difficult for a human brain to digest rich multivariate dynamics. When doing so, it tends to “integrate” it into simple “now and then” terms, thus disregarding a great deal of valuable information and missing revenue-generating opportunities.
On the other hand, computers cannot accurately estimate present state because of their lack of additional, frequently imprecise, ‘real world’ information. So, i-Rates is designed to emphasize the strong abilities of both, human and computer, thus reducing the error rate.
- What is the final optimization goal? Does the system just optimize revenue or the bottom line (profits)?
The i-Rates system is targeted to optimal strategic control. It maximizes total expected room revenue adjusted to statistical estimation of revenue from other departments, less variable costs. The revenues and costs are extracted from the hotel’s financial structure, taking into account historical seasonal variations. Due to the fact that costs are proportionate to rooms sold, this adjustment optimally shifts the pricing position depending on current progress in sales. Taking into account additional revenues has a similar effect and it is certainly essential for full service properties.
- How does the algorithm calculate the daily rate?
Is it just following the pricing of others or does it actually take into account Elasticity and Capacity?
The core engine of i-Rates is based on a proprietary reinforcement learning  algorithm. i-Rates’ dynamic pricing methodology extracts from the fact that hotel bookings and pricing evaluations follow relatively stable patterns or their combinations, that are specific for the property, the season, the hotel’s location, and the market conditions. A rich and informative library of these patterns is encrypted in the observed historical bookings and may be effectively withdrawn by i-Rates dedicated module. These patterns are extracted from a reasonable amount of historical data (typically 1 year) via our algorithms of demand de-censoring. Clusters of these historical patterns serve only as the basis for reconstruction of the current running pattern via a maximum likelihood principle.
The algorithm embeds three levels of adaptation:
- Strategic selection of booking patterns of the property (e.g. once every 1-3 years)
- Recognition of current booking pattern or pattern mix (with optional switching between patterns, weekly or less often)
- Adaptive dynamic pricing based on the current sales state and capacity (daily or hourly)
Each pattern comprises both dynamic flow strength and elasticity. Both dynamics of recognition and de-censoring are based on specific neural network methods.
To provide the observability of a controlled system, i-Rates constantly tracks the booking dynamics for every single night a year ahead.
The basic pricing decision is subject to competitors’ constraints by means of proper adjustment of customer flow via elasticity. Then the algorithm evaluates recent dynamics and expected reward against the expectation coming from flow pattern collection. This “self-healing” measure is used as an internal indicator of additional opportunities or threats concerning sales for a given business night. This indicator, together with the sales position, is used to restrict the distribution channels with a different profitability margin. And finally, states and dynamics of adjacent business nights are analyzed to propose possible stay restrictions (such as close-to-arrivals and other stay limits).
The whole multi-step and multi-stage control system may be fine-tuned and additionally stabilized with optional, informative user input, mostly in the form of additional constrains.
- Would the system detect a sudden increase in occupancy, if so – how will it react?
This change will be processed by all adaptation levels of the i-Rates algorithm. First, if this increase is sufficient to switch to a different flow pattern, this will be done automatically. If the tendency is not persistent, i-Rates will return to the previous scenario. Next, local adaptation will adjust the price in accordance with strategic expectation. Both actions will be followed by alerts, to keep the user informed.
- What data is used for neural network learning?
Do you analyze the hotel’s historical data in order to build future demand patterns?
None of the historically observed patterns are used for future business nights pricing directly. It is too optimistic to expect the repetition of the history. Instead, the library of historical patterns of unconstrained demand flow (not sales flow - these are censored by our pricing decision) should be used as the base (in terms of Bayes statistics - the prior) for tracking of currently traded flow. Optimally reconstructed patterns are used to estimate expectations of future reward based on current observed state and current trial decisions.
Neural networks are used in de-censoring algorithms (reconstruction of the customer flows from the sales flows) as well as an estimation of the likelihood of currently reconstructed patterns. They consume pricing and other control variables, and capacity dynamics adjust to the time left before the business night.
Note that our algorithm is not trying to predict the temporal dynamics of future demand per se. It is not time series forecasting. Instead, the algorithm is based on the estimation of the most probable future reward from a given state and control. This is augmented with an estimation of the most probable customer flow rating. Basic optimization is done via Belmann’s dynamic programming principle, in contrast to optimization of static function with embedded forecasting.
- What metrics are used in calculations?
Internally, the algorithm operates with statistical estimates of reward-related variables and probabilities of dynamic trajectories, such as customer flows or occupancy curves. Final valuation is done in terms used in everyday practice of revenue management, such as RevPAR, ADR and Occupancy rate. These are properly adjusted to take into account additional revenues and variable costs.
- How are you solving the problem of over correction (adjusting rates too frequently)?
Are the prices, calculated by the program, discrete? If so, is there a way to set the interval?
i-Rates will provide specific pricing recommendations. These reported prices are discrete, in accordance with the general RM practice. Internally, the use of different forms of prices varies depending on the algorithm context. E.g. competitors’ prices are analyzed as is, to obtain unbiased estimates. It is important to take into account that optimal pricing policy for discrete and real-valued prices in general, is different. So the fact that our future reported prices must be discrete, imposes additional constraints to the dynamic optimization.
Discrete pricing is a good, practical remedy to avoid super-sensitivity of the algorithm. It is known that too high of frequency of adjustments may interfere with business requirements, such as the risk of loss of branding value for the hotels and disorientation of customers.
Fluctuating decisions are typical for linear reactive control algorithms, such as plan/trend following. Strategic pricing in i-Rates is much less inclined to such over-adaptation.
- Does the user have an ability to input special dates, such as holidays, busy dates, dates needing stay restrictions?
There are several options for managing individual dates, starting from strategic restrictions set in initial seasonal tables, to the detailed control constrains at the level of an individual room type. Identifying special dates and individual treatment for each is the key operational feature of i-Rates.
- When a manager possesses additional market information and would like to assist the system in making calculations, does he/she simply input a corrected price for that business day or, instead, add information about the demand levels asking the system to recalculate the decisions?
In i-Rates, the process of interaction between the manager and the machine is strictly formalized. First, the algorithm proposes possible changes in control decisions for automatically identified business nights. These proposed decisions take into account all available information, as well as (optional) constrains, specified before.
Next, the manager may optionally specify his/her new constrains for certain nights. Normally, this should be done if new important market information becomes available (such as regional news, changes in plans for demand-generating events etc.). If the actual observed sales flow contradicts with the previously established constrains, the manager is immediately notified. This prevents mistakes caused by incorrect input or over/underestimated demand levels on the manager’s part. Newly set constraints will either become active immediately (if the manager selects to recalculate the pricing) or otherwise will be reflected in following decisions.
Finally, the manager confirms the machine-generated decisions (either by agreeing to all or modifying some). These will become published in distribution channels, or reported for further review based on user preference.
Technically, the manager may directly set the rating of any business day, if there is a strong reason to do that. But poor constraints may cause frequent alerts of low flow likelihoods or hitting constraint limits. That’s why the recommended practice is to adjust the rating constraints and allow the machine to take them into account during recalculations. We created an intuitive and simple interface to help the user conveniently and quickly provide additional information when available.
- Does the system have a set of configurable business rules so similar channels can be managed the same way to avoid parity issues?
Resulting pricing decision of iRates is the rack rate, which is pushed to all relevant distribution channels, considering the specifics and policies of each channel, which eliminates parity issues.
Different distribution channels are configured into a small number of groups, each managed simultaneously as a whole. When estimated sales flow is sufficient enough to reach high occupancy without the loss of revenue (and profits), the system will suggest closing less profitable channels in order to maximize the resulting yield.
- How do you solve the problem of overbooking by extranets?
The overbooking policy as a whole, and potential risks of occasional overbooking from extranets, is mitigated by a constant monitoring of the sales flow, and setting allocation limits based on expected sales for each day in the future. To prevent overbooking, the system pushes a close-out request to all extranets when the number of remaining rooms reaches a specified limit.
- Does the system take into account competitive prices when calculating daily rates?
Does it display information about the competitive prices to the user?
Competitors’ prices are already reflected in basic pricing decisions, since resulting customer and sale flows are formed in the real competitive environment. Additional adjustments are made when proposed prices significantly deviate from the stable position at the equilibrium, when observed sales are self-consistent with reconstructed customer flow. In such cases prices are adjusted via an effective elasticity correction algorithm. The Manager may also implement a specific policy by adjusting the rating of the traded night in case of aggressive competition.
Pricing positions of competitors are displayed in the GUI, both current state and stored dynamics. Both Graph and table views are available.
- Does the system provide comprehensive graphs/reports for in-depth analysis of data?
What reports/graphs are available?
iRates is designed with a rich user interface, where the most relevant information is readily available and aligned with proposed and confirmed user decisions. In addition, major metrics can be graphically presented in dynamics (vs. time), and the same metrics can be plotted for different traded nights (vs. business date). On the other hand, our goal is not to compete with a hotel’s Property Management Systems, where all property/sales information may be displayed via hundreds of reports. Instead, we concentrate on such forms and such content that is the most relevant to pricing decisions and control actions and in many cases, not available in the PMS.
The reporting engine of iRates is designed in an extensible manner, so new reports and graphs will be added during the product’s lifetime. But our main direction is to aggregate the information into a compact and meaningful form, such as “traffic lights”, indicating points that require special attention.
 Reinforcement Learning: http://en.wikipedia.org/wiki/Reinforcement_learning