Of all the technology categories in hospitality, revenue management is the one that engineers find most interesting once they understand what it actually does.
The job of a Revenue Management System (RMS) is to answer, for every room type, at every point in the booking window, the question: what is the optimal price to charge right now? Not the maximum price the optimal one. A price set too high fills fewer rooms. A price set too low fills all rooms but leaves money on the table. The RMS is trying to find the price that maximises total revenue given real-time demand signals and constrained inventory.
This is a genuinely hard optimisation problem. Let me explain how it works.
The core model: expected marginal revenue
The fundamental concept in revenue management is expected marginal revenue the revenue you expect to generate from selling a room at a given price, weighted by the probability of selling it.
If a room is priced at $200 and history suggests a 90% probability of selling at that price on a Tuesday in October, the expected marginal revenue is $180. If the same room priced at $300 has a 50% probability of selling, the expected marginal revenue is $150. The $200 price wins even though it’s lower because the probability-weighted outcome is better.
The RMS is performing this calculation continuously, for every room type, across every future date in the booking window, and updating prices accordingly.
The inputs: what an RMS needs to function
Historical demand data. The model needs to know what has happened before what occupancy levels, what booking patterns, what rates achieved, on similar dates in prior years. This is why RMS quality improves dramatically with data age: a system with 3 years of property history is substantially more accurate than one with 6 months.
Current pickup pace. “Pickup” is the rate at which reservations are accumulating for a future date. If a Saturday three weeks out has 40% occupancy today, that might be ahead of pace (good likely high demand, raise rates) or behind pace (concerning possible low demand, lower rates or increase visibility). The RMS needs to compare current pickup against historical pickup curves for similar dates.
Competitive pricing. Rate shopper integrations pull competitor rates from OTAs in real time. If your comp set is raising rates for a weekend, that’s a demand signal. If they’re dropping rates, that’s also a signal. A modern RMS incorporates this data automatically.
Events and demand drivers. Conferences, sporting events, concerts, public holidays, and school calendars all affect demand in patterns that historical data partially captures but never fully predicts. Better RMS systems allow revenue managers to flag upcoming events and adjust model assumptions accordingly.
Booking window elasticity. Demand at different points in the booking window behaves differently. A leisure traveller booking 90 days out is more price-sensitive than a business traveller booking 3 days out. The RMS needs to model this elasticity and adjust pricing accordingly generally, rates increase as the arrival date approaches and inventory tightens.
The output: price recommendations and restrictions
An RMS produces two types of output:
Rate recommendations. For each room type, for each future date, a recommended rate (or rate range). These may be expressed as a BAR (Best Available Rate) value, a percentage adjustment to a base rate, or a specific rate tier to open or close.
Restrictions. Minimum length of stay (MLOS) restrictions are particularly important. If a Saturday is very high-demand but the surrounding nights are soft, the RMS might recommend a 2-night minimum stay for Saturday arrivals forcing guests to book Friday-Saturday or Saturday-Sunday, which fills the shoulder nights and increases total revenue per booking.
How an RMS connects to the rest of the stack
The integration topology matters enormously:
Historical Data (PMS) ──┐
Competitor Rates ───────┤
├──→ RMS Engine → Rate Recommendations
Market Demand Data ─────┤ ↓
Event Calendar ─────────┘ PMS (rate update)
↓
Channel Manager (distribution)
↓
OTAs / Booking EngineThe PMS is both a data source (historical reservations) and a downstream consumer (the RMS writes recommended rates back to the PMS, which then distributes them via the channel manager).
The latency of this loop matters. An RMS that updates rates once per day is missing intraday demand signals a sudden burst of bookings for a future date that should trigger a rate increase. Better systems update every few hours; the best update in near real time.
The engineering challenges
Sparse data problems. A 50-room boutique hotel has far less historical data than a 500-room city hotel. The model has wider confidence intervals and is more susceptible to outlier events. Small properties either get worse predictions or need more aggressive smoothing, which itself introduces error.
Non-stationarity. Hotel demand patterns change over time new competitors enter the market, events shift dates, travel patterns evolve. A model trained on pre-2020 data is partially wrong for post-2020 reality. RMS vendors handle this differently: some retrain continuously on rolling windows; others require periodic manual recalibration.
Constraint conflicts. Revenue management decisions interact. An MLOS restriction that maximises room revenue might reduce F&B spend if it locks out single-night guests who tend to dine at the restaurant. A truly optimal RMS would model total guest spend, not just room revenue. Most don’t they optimise the room, and the rest is someone else’s problem.
Human override. Revenue managers don’t always accept the system’s recommendations. They override based on intuition, relationships, and information the system doesn’t have. Good RMS systems track override frequency and outcomes did the override outperform the recommendation? and use that to improve the model. Overrides are data.
What I find most interesting about this space
Revenue management is one of the few areas in hospitality technology where the algorithmic complexity is genuinely high. Most hotel tech is an integration and data-plumbing problem. RMS is an optimisation problem with real uncertainty, real stakes, and real feedback loops.
The models used by the leading systems IDeaS, Duetto, Atomize are not published. But the underlying approach is academically well-documented: stochastic demand models, constrained optimisation, dynamic programming for booking window decisions. If you come from a background in quantitative finance, operations research, or machine learning, you will find this domain familiar and interesting.
The opportunity I see: most RMS systems still operate as black boxes that output recommendations. There is a generation of tools to be built that make the model’s reasoning transparent showing the revenue manager why a rate was recommended, not just what it is. Trust in automated pricing increases dramatically when the reasoning is legible.