What is a hotel revenue management system? When a small team needs one

A hotel revenue management system is software that reads a hotel's booking history, the rooms already on the books and market prices, then returns suggested room rates and restrictions for each date, each with its reason, for a person to approve. It decides prices; a channel manager distributes them.

The pricing spreadsheet has forty tabs, and the person who built it is on leave. Three channels are selling the same Saturday at three different prices, and nobody in the building can say which one is right. If that scene is familiar, this article will help you decide whether you need a revenue management system or a better routine. It explains what the software reads, what it hands back, what it needs from your hotel first, where it cannot help, and how to test any vendor's claims.

What is a hotel revenue management system?#

It is software that turns booking data and market prices into suggested room rates and selling restrictions for each date, each with its reason, for a person to approve.

It is not a selling tool. It does not push rates to channels, take bookings or replace the front desk. The channel manager distributes what the revenue system decides, and the property management system records what actually happened. Keep those three jobs separate in your head and most vendor pitches become easier to read.

The unit of output is a decision per room type per date: a price, and often a restriction. Common restrictions are a minimum length of stay, closed to arrival, closed to departure, or a stopped rate plan. A rate shopper collects competitors' public prices; a revenue system uses those as one input among history, demand already on the books and the restrictions already in force.

The category is wide. At one end sits a rules-based tool that applies the hotel's own written pricing policy automatically. At the other end sit products that add statistical models on top. The buying questions, covered later in this article, are the same for both.

A person stays in the loop. The system proposes, the revenue manager or owner approves, and the approval is recorded so the decision can be explained later, to an owner, an auditor or yourself in November. And it only prices what it is allowed to price: rooms promised to a wholesaler, held in an allotment or blocked for a group are usually outside its authority.

Revenue system, channel manager, rate shopper: three different jobs#

If you are new to the routine these tools support, start with hotel revenue management as a working routine.

What does a revenue management system read, and what does it hand back?#

It reads three things: what happened, what is already sold, and what the market is asking. It hands back a price and a restriction for each date, with the reasoning attached.

History means occupancy by date, the rates actually sold rather than the rack rate, cancellations, no-shows, length of stay, and which segment bought each room night. Bookings on the books means pickup by date and segment, so the system can compare this season's pace with the same period last year instead of with a feeling. Market prices means public rates for comparable room types on the same dates, plus the events, holidays and closures the hotel tells it about.

What it hands back is a suggested rate per room type and date, and restrictions such as a minimum stay, a closed arrival day or a closed rate plan. The reason matters more than the number. A usable suggestion names the rule or comparison that produced it, so a person can agree, adjust or overrule it in seconds.

Some things it cannot see unless the hotel enters them: costs, a group's value to the restaurant and bar, a returning guest's history, a contract signed last month, a renovation planned for March. Treat every suggestion as an answer to a narrower question than the one you actually face.

A suggestion arrives with its reasons, and a person decides#

For a deeper check of a single recommendation, see what a revenue manager should verify in an AI rate suggestion.

What does it need from your hotel first?#

Clean segments, a full trading history and a live link to the hotel's own system. Without those three, a revenue system produces confident numbers from bad inputs.

Segments come first. Each rate plan should mean one thing: direct flexible, direct non-refundable, OTA, corporate, group, wholesaler. If one plan carries three kinds of business, the history cannot be compared with anything, and comparison is the whole method.

History should cover at least one full cycle containing a high and a low season, so the system has a baseline for the current pace. A new property starts with market data only, and the vendor should say so plainly rather than pretend otherwise.

The link matters as much as the data. If the system reads a spreadsheet exported on Mondays, its suggestions are a week old. The link should carry bookings, cancellations and current rates in both directions. Someone must own the output: a system that suggests to nobody changes nothing. And the hotel needs a written policy first: floor and ceiling rates, how far ahead to price, which segments may be closed and when. The system applies the hotel's policy; it does not invent one.

Finally, time. Someone has to review suggestions, usually daily or a few times a week. That person-hour belongs in the cost comparison, next to the licence.

Where it has little to change: contracted rates and allotments#

A revenue system prices the rooms the hotel is still free to sell. Rooms already promised to a tour operator at a contracted rate, or held in an allotment, are outside its reach.

A resort that signs euro contracts with wholesalers before the season has fixed a large part of its inventory and its price. The system can only work on what remains. Allotments behave the same way: rooms held for a partner until a release date are not available to price, and the system sees them as committed until they come back into the pool. Group blocks remove rooms from the pricing pool at a fixed rate, and the system cannot reprice them mid-stay.

What it can still do is real work: price the free portion, flag dates where that portion is thin, and show what the contracted business earns against what the open market might pay for the same rooms. The strategic question, how much to commit, at what rate and with which release terms, is a commercial decision made with the partner. It is not a software setting. On that trade-off, see static or dynamic rates for tour operators and wholesalers.

A practical check before buying: count the share of room nights normally committed before the season opens. That share is the part of the business the system cannot touch.

Spreadsheet and weekly meeting, or a system? A test#

Judge by decisions per week, not by room count. When rate decisions outgrow the time the team can give them, a system starts to earn its place.

Count the decisions: how many dates and room types does the team actually reprice in a week, and how many channels does each new price have to reach. Then count the inputs: how many sources must be checked before each decision, between the on-the-books report, competitor prices, events and the group pipeline.

A spreadsheet is strong when the property has few room types, one or two channels, a stable base of repeat or contracted business, and one person who knows the file well. Signs the spreadsheet is failing: prices are set once a season, the file breaks when its author is away, two channels show different prices for the same night, or nobody can say why a rate was changed.

Signs a system is premature: the segments are not clean, the link to the hotel system would be a manual export, or nobody has time to review suggestions. A middle step that is never wasted: keep the spreadsheet, fix the segments and write the pricing policy down. That work is needed before any purchase, and it makes every later offer comparable. For the broader picture of when software replaces the file, read when a small property outgrows the spreadsheet.

As a rule of thumb, three or more and a system is worth pricing; fewer, and a spreadsheet with a weekly meeting is still the cheaper answer.

Questions for a vendor before a demo#

Ask for one suggestion built from your own dates, with its reason, and ask who approves it and how it is undone. A demo on the vendor's sample hotel answers none of those.

Also ask about the exit: how rates and history come out if the hotel leaves, and what the hotel still owes after the contract ends. Do not ask for a revenue promise. Ask for a worked example on your own dates, and compare vendors on the same example. To make those offers genuinely comparable, build a requirements document before the demos start.

What to do next#

Before you book a demo, write down the last four weeks of rate decisions: the date, the room type, the old rate, the new rate, the reason and who approved it. If you cannot fill that page in, the problem is the routine, not the software, and the segment and policy work above tells you what to fix first. If you can fill it in, you already hold the test any vendor must pass, and the questions in this article turn a demo into a comparison.