Machine Learning for Hotels and Revenue Management

The rate decision nobody has time to make properly

A 60-room independent hotel sells through its own website, two or three online travel agents, a handful of corporate accounts and the odd wedding block. Somebody, often the general manager between other jobs, looks at the pickup, checks what the hotel down the road is charging and nudges rates. On a busy week that happens once. On a quiet week it barely happens at all.

Revenue management is a forecasting problem wearing a pricing hat. If you know how many rooms will be booked for each night, how many of those bookings will cancel and how demand responds to price, the rate decision becomes much easier. Machine learning is well suited to all three predictions, which is why it sits inside every serious revenue management system.

What machine learning does in hotel revenue management

• Demand forecasting by stay night. Using booking pace (how far ahead of each night rooms are being picked up), seasonality, local events and day of week.
• Cancellation and no-show prediction. Scoring each booking by channel, lead time, rate type and guest history, which informs how far to overbook.
• Price response. Estimating how bookings change when rates move, by segment, so recommendations are not simply 'match the competitor'.
• Length-of-stay controls. Suggesting minimum stay restrictions on nights where a single-night booking would block a more valuable longer stay.
• Group and event displacement. Estimating whether a discounted group block displaces transient guests who would have paid more.
• Ancillary demand. Forecasting restaurant covers, spa appointments and breakfast numbers from room bookings, which helps staffing and purchasing.

Cancellation prediction and overbooking, with the arithmetic

Flexible rates and online travel agent bookings cancel at very different rates from direct, non-refundable ones. A hotel that treats every booking as equally likely to arrive either overbooks blindly or leaves rooms empty on nights it thought were full.

Suppose, as an illustration, a Saturday shows 58 of 60 rooms sold, and a cancellation model estimates that about six of those bookings will not arrive. Selling three or four more rooms is a reasonable decision; selling ten is a walked guest and a bad review. The model's job is to put a sensible number on that judgement, and the revenue manager's job is to decide how much risk the hotel will take.

Overbooking without a cancellation model is gambling. Overbooking with one is still a judgement call, just a better informed one.

Buy an RMS or build your own?

This is the most important decision, and for most independent hotels the honest answer is to buy. Established revenue management systems have years of product work behind them, integrate with common property management systems and channel managers, and cost far less than a custom build.

Custom work makes the most sense around the RMS rather than instead of it: forecasting food and beverage demand, modelling event displacement, predicting which past guests will rebook direct, or joining data the RMS never sees.

Why pricing recommendations need a human in the loop

Fully automated pricing is possible and sometimes fine for simple inventory. For most hotels it is a risk. Models learn from historic demand, so they handle the unprecedented badly: a major concert announced last week, a rail strike, a local flood. A revenue manager who reads the news will beat the model on those nights.

1. Set floor and ceiling rates the model cannot cross
2. Show the reason for each recommendation, such as pace ahead of last year
3. Let the revenue manager accept, adjust or reject in one click
4. Log overrides and review whether they helped, which improves both model and manager

There is also a reputational ceiling. Guests notice extreme price swings, and a rate that is technically optimal for one night can annoy a repeat guest enough to lose several future stays.

Data you need and where it hides

Revenue models need booking history with creation dates, not just stay dates, because pace is the most predictive signal. Many property management systems store the final state of a reservation but not the history of changes, and some overwrite cancellations. Check this first.

• Reservation history with booking date, stay dates, rate code, channel and cancellation date
• Two or more years of data to capture seasonality, marking any unusual periods
• A local events calendar, which is often more predictive than competitor rates
• Competitor rate data if you already collect it, used as context rather than a target

Signals from outside the hotel

Your own booking pace tells you a lot, but demand often moves because of things happening outside the building. A conference centre releasing its calendar, a football fixture list, university graduation weeks, a new airline route or a festival on the other side of town can all shift demand weeks before bookings reflect it.

• Event calendars for venues, sports grounds and universities within reach of the hotel
• School and public holiday dates across the countries your guests come from
• Flight schedule changes for leisure destinations
• Weather forecasts for short lead-time leisure stays, used with caution

Adding these is where a custom layer can beat a generic product for a particular location. It is also where effort is easily wasted, so we test each external signal on past data before wiring it in. If a source does not improve the forecast on last year's nights, it does not go in.

How we would help a hotel group

At SpiderHunts we would first check whether an existing RMS already does the job, and say so if it does. Where custom work is justified, we start with the forecast and the cancellation model, measure accuracy against what the team currently expects, and only then build rate recommendations on top.

Our post on AI pricing optimisation and dynamic pricing covers the pricing side in more general terms, and AI integration for hospitality and events covers guest messaging and admin. The modelling itself sits within our machine learning service.

Frequently asked questions