Hotel Revenue Management System: Selecting and Trusting the Algorithm

The 2026 Mews Hotelier Survey, which covered more than 500 properties between December 2025 and March 2026, found that 98% of hoteliers have used AI across their operations in the last six months. Of those surveyed, 92% are optimistic about AI in hospitality and 83% trust AI tools to support decision-making. Mews is a hotel technology vendor and the survey should be read with that in mind, but the direction matches other sources.

The governance picture is weaker. In the same survey 41% of hotels have no formal AI policy, relying on verbal guidelines or nothing at all. The contrast in trust is striking: properties with a formal AI policy report 92% strong trust in AI, compared with 49% among those with no guidelines. A policy is not paperwork; it is what turns experimentation into reliance. For a Director of Revenue, this is the most practical finding in the data.

h2c and Cloudbeds reached a similar conclusion from the chain side. Their AI & Automation in Hospitality 2025 report, based on 189 quantitative responses and 26 executive interviews across 171 hotel chains, found that 78 percent of chains already use AI and 89 percent plan to expand applications in the next 12 to 24 months. Only 6 percent operate with a comprehensive AI strategy (Exhibit 2). Activity is high, direction is thin.

Revenue management sits at the centre of this gap because it is where an algorithm directly sets price, and therefore revenue. The consequences of a poorly supervised model are visible within days, in rate positioning and in owner reports. That is also why revenue is where governance pays back soonest.

Executive teams should also be clear about what a policy cannot do. It does not make a poor model good. What it does is create the conditions in which a good model is used consistently, challenged when it is wrong and improved over time. That is the difference between technology that is merely installed and technology that is relied on.

Owners and franchisees deserve a seat in this conversation. They carry the financial consequence of pricing decisions made by a system they did not choose, and they will ask who is responsible when results disappoint. A short, plain-language description of how the algorithm works, what limits apply and who reviews it answers most of those questions before they become disputes.

What to do: before any new system is selected, write a one-page AI and pricing policy that states who may change a model setting, what override limits apply, how decisions are logged and how exceptions are escalated. Share it with owners and general managers.

Revenue management software is no longer a niche purchase. In Duetto’s 2023 survey, 82.3% of respondents were using a revenue management system, up from 67.6% in the 2022 survey, and its 2025 trends report found that 54.5% planned to buy an RMS in 2025 while 61.1% aimed to increase technology budgets. Duetto sells an RMS, so these figures describe an engaged audience, not the whole market. Skift Research estimated in 2021 that only 28 percent of hotels used RMS tools, which suggests how recently adoption has broadened.

Adoption does not guarantee gains. The State of Distribution 2026 report, produced from data on more than 270 hotel brands and more than 58,000 properties across 53 countries, found that more than half of hotels use or are procuring generative AI, but fewer than one in 10 report that it has reduced manual work by more than 30 percent. It also found that more than 80 percent of commercial teams spend one to two days a week manually producing and analysing reports, while fewer than 30 percent have invested in dedicated reporting tools.

The picture is of tools bought faster than operating models were redesigned. A system that forecasts demand but cannot easily be fed clean data, or whose outputs cannot be reported without manual rework, shifts effort rather than removing it. The report adds that 55 percent of hotels report little or no change to their distribution strategies despite AI-generated search traffic, which suggests that the commercial response lags the technology.

For the Director of Revenue this means that the business case should rest on specific, measurable outcomes: time released from reporting, forecast accuracy by segment, and rate decisions made at the right speed. A case built on a generic uplift claim from a vendor is difficult to test and easy to dispute later.

There is also a sequencing point. Many groups buy the system, then discover the data issues, then write the governance rules after an incident. Reversing that order is cheaper and less disruptive. The cost of the preparatory work is small compared with the licence and implementation budget, and it improves every vendor’s performance.

What to do: define three baseline measures before procurement (hours spent on reporting, forecast error by segment and the share of rates changed manually), and require every vendor to commit to improving them in writing.

The h2c and Cloudbeds report identifies the barriers to AI in hotel chains as lack of expertise at 62 percent, unclear strategy at 51 percent and integration challenges at 45 percent (Exhibit 3). Each of these is a data and operating-model problem, not an algorithm problem. Revenue management is where they bite hardest, because the system depends on consistent segment, channel and rate definitions across properties.

Segmentation drift is common in groups that have grown by acquisition or franchise. One property codes a negotiated corporate rate as corporate, another as a discount, a third as a promotion. Group blocks are booked under different codes depending on the sales team. When these histories are fed into a forecasting model, the model learns the inconsistency. It will propose rates that look plausible at portfolio level and wrong at property level, and revenue managers will override it, which then pollutes the data further.

Cleaning the data is unglamorous and tends to be postponed until implementation, when it becomes the critical path. It is more efficient to do it first. Agree a single segmentation taxonomy, map every property’s legacy codes to it, and test the mapping on two years of history. The exercise often reveals revenue leakage, such as rate fences that no longer work, before any software is purchased.

This work also improves the vendor selection process. When the data is in order, a vendor’s proof of concept is comparable across candidates, because each is tested on the same clean history. When it is not, results differ for reasons unrelated to the quality of the algorithm.

Procurement teams can help by requiring vendors to state, in the contract, the baseline measures against which improvement will be judged. Vendors who are confident in their product tend to accept this. Those who prefer generic claims of uplift often do not, which is itself useful information at the selection stage.

A practical test of readiness is to ask a property revenue manager to explain why a particular segment produced a particular share of revenue last quarter. If the answer takes a day of reconciling spreadsheets, the data is not ready for an algorithm. If it takes minutes and the same answer comes from a second property, it probably is.

What to do: appoint a data owner for segmentation, publish the taxonomy and complete a mapping audit on a sample of properties before the request for proposal is issued. Treat it as part of the programme, with a named lead and a deadline.

Hotel revenue management system demonstrations tend to emphasise dashboards, automation rates and the breadth of modules. These are easy to compare and poor predictors of value. A better test is how the system behaves on your data, in your hardest situations: a compression night, a group displacement decision, a sharp drop in a feeder market, a rate-parity dispute with an online agent.

We suggest a structured pilot on a representative sample of properties, run in shadow mode for long enough to cover a peak and a trough. Compare the system’s recommended rates and forecasts with actual results and with the current process, segment by segment. Ask the vendor to explain each of a set of contested recommendations in terms a general manager can follow. If the system cannot explain a decision, the revenue manager cannot defend it to an owner.

Integration is the other determinant of cost. The system must exchange data cleanly with the property management system, central reservations, channel manager and reporting layer. h2c and Cloudbeds report integration challenges for 45 percent of chains, and that is before a generative layer is added. Ask for a reference customer with a comparable technology stack and speak to them without the vendor present.

Commercial terms deserve the same discipline: pricing models linked to rooms or revenue, exit and data-portability rights, model-change notification and the vendor’s approach to training on your data. A contract that does not allow you to leave with your history is a form of lock-in.

Property teams often ask for local flexibility, and some of it is justified: a resort in a seasonal market has different needs from a city-centre business hotel. The taxonomy should therefore be stable at the core and flexible at the edges, with a defined process for adding a local segment and a rule that every local segment must map to a core one.

What to do: score vendors on a weighted scorecard that gives most weight to pilot results, explainability and integration, with features and price as supporting criteria. Exhibit 4 gives a starting point.

Market conditions are part of the case. CoStar reported that US hotels recorded their first full-year occupancy and RevPAR declines since 2020 in 2025. Full-year occupancy was 62.3%, down 1.2%; average daily rate was US$160.54, up 0.9%; and RevPAR was US$100.02, down 0.3%. This is a single market, but it illustrates a pattern in which rate growth no longer compensates for softer occupancy.

In a weaker market an algorithm faces a harder problem. Raising rates on strong nights is straightforward; deciding how far to cut on soft ones, without damaging positioning or triggering parity issues, is not. Systems trained mostly on years of rising rates may be biased toward a pricing posture that no longer fits. A Director of Revenue should ask how a model was validated in periods of falling demand and how quickly it adapts when the pattern changes.

Owner and asset-manager scrutiny also rises when RevPAR is flat. A system adopted in a period of growth can be blamed for results that are really about demand. Clear baselines, set before implementation, allow the group to separate the effect of the system from the effect of the market and to defend the investment fairly.

The same logic applies to dynamic pricing hotels use during events. Rate spikes can produce short-term revenue and long-term reputational damage if guests compare their price with neighbours or with a previous visit. Guardrails on the size and speed of rate movements are not a limit on the algorithm; they are a protection for the brand.

It helps to involve a small group of general managers in the pilot review. They are the people who must trust the system’s output when an owner asks why a rate moved. If they find the explanations credible during the pilot, the rollout is far easier. If they do not, that is better learned before the contract is signed than after.

A final consideration is the role of competitive-set data. Many systems use competitor rate shopping as a major input, and in a soft market those rates may themselves reflect discounting by rivals. A model that follows the set downwards without regard to the property’s own position can amplify a decline, so the guardrails should include a floor linked to the property’s cost and brand position.

What to do: set maximum rate-change limits by segment and by notice period, review them quarterly against actual performance, and require the vendor to show model performance in falling-demand periods.

Dynamic pricing in hotels sits within a tightening consumer-protection environment. In the United States the Federal Trade Commission’s rule on unfair or deceptive fees took effect on 12 May 2025 and requires businesses to tell people upfront the total price for short-term lodging. The agency’s own example describes a resort charging a nightly rate of $199 plus a mandatory resort fee of $39 per day; the total price is what must be shown.

In Europe, the Digital Fairness Act consultation, as reported by Osborne Clarke, is seeking views on an outright prohibition on drip pricing. If adopted, it would affect how mandatory charges are displayed across the single market. Revenue systems that optimise the base rate and treat fees separately will need their outputs to be reconciled with a total-price presentation.

This is a design issue for the revenue system and not only for the booking engine. The algorithm needs to optimise the total price the guest sees, including mandatory fees, taxes and any dynamic components. Where groups set resort fees or similar charges centrally, the revenue team should be part of that decision, because the fee affects the rate competitiveness the algorithm is trying to manage.

Personalised pricing is a second area of risk. Offering different prices to different guests on the basis of data about them raises questions of fairness and, in some jurisdictions, data protection. A revenue system that uses guest-level signals should have a documented rationale and a legal review.

Regulators and courts have yet to settle how algorithmic pricing should be treated in every jurisdiction, and group counsel should watch the debate on shared data and tacit coordination between competitors using the same vendor. A sensible precaution is to ask each vendor how it prevents the use of competitors’ non-public data and to record the answer.

What to do: ask legal and compliance to review the pricing logic, the display of fees and any guest-level personalisation before go-live, and keep a record of the review so that the group can show how decisions were governed.

Mews found that 59% of hoteliers say front desk welcome and check-in should stay human-led, and that among the most AI-proficient properties, 52% identify revenue growth as the primary outcome. Those two findings point to the same design principle: automate where the work is repetitive and the rules are clear, keep people where judgement and relationships matter, and point the technology at the outcome that matters commercially.

In revenue management the repetitive work is the daily rate review, the pick-up reports and the first-pass forecast. The judgement work is deciding when the model should be overruled, how to handle a displaced group, how to respond to a competitor’s move, and how to explain the result to an owner. A revenue manager who gives one to two days every week to manual reporting, as more than 80 percent of commercial teams do according to the State of Distribution data, has little time left for the second kind of work.

This changes the skills the role requires: data literacy, model supervision, experimentation and communication. It also changes the structure. A central team can supervise the algorithm across a portfolio, while property-level roles focus on local market knowledge and on feeding exceptions into the system. The group should publish what the algorithm decides alone, what it recommends for approval and what remains with people.

Overrides need to be managed. Unlimited overrides undermine the system; none at all remove accountability. A useful practice is to log every override with a reason, review the log monthly, and measure whether overrides improved or reduced revenue. Over time the evidence shows where the model needs retraining and where human judgement adds value.

The best groups treat the first year of an AI-assisted revenue function as a learning period with explicit goals and a review point at which the group may expand, adjust or stop. That framing makes it easier to be honest about results, and it turns the override log and the exception review into a source of improvement.

What to do: write the new role description, define a decision-rights matrix for algorithm, revenue manager and general manager, and put a governance cycle in place with a monthly review of overrides, forecast accuracy and exceptions.

Karter McKinley supports hotel groups through its AI & Technology implementation service. We help structure the segmentation clean-up, run vendor selection and pilot design, define governance and decision rights, and plan the change to the revenue manager role. We do not endorse or resell any particular revenue management product.