You Can't Prove Your RMS Paid Off. Here's How to Measure It Anyway.

For the owner or GM who has to justify a revenue system — at the buying decision, at budget season, or at renewal. The honest answer to “how will I know it worked?” isn’t a number. It’s a method.

Somewhere in every revenue software conversation, the owner asks the question that actually decides it: “How will I know it worked?”

It’s the right question, and most answers are bad. Vendors quote a percentage — “our hotels see +8% RevPAR” — as though it were a measurement rather than an average of other people’s good years.

Here’s the honest version. You can’t fully prove a revenue system paid off. What you can do is build a defensible case from a portfolio of imperfect signals plus a floor of measurable savings — not provable, but defensible, which is the whole article.

The question every owner asks

It surfaces at the buying decision, at budget season, and hardest at renewal: what did I get for a year of invoices? At the enterprise end, an RMS is typically custom-quoted and materially more expensive than independent-hotel tooling; even at the independent end, it’s a line item someone has to sign off — usually not the person using it.

The difficulty isn’t financial. A revenue management system works by changing decisions, and decisions don’t leave receipts. A new boiler either heats the building or it doesn’t. A rate you raised in March produced one outcome; the other was never recorded, because it never happened.

Why you can’t prove it, and why budget and last year don’t help

The night you priced happened once. You raised Saturday and sold out; you can’t rerun it at the old rate. Your control group is the same hotel on the same night, and it’s busy — hotels can rarely A/B test themselves the way a website can. That obstacle has a proper home (the autopilot essay makes the full case), so this article moves on: stop hunting for one clean proof and triangulate imperfect signals instead.

First, clear away the two numbers every hotel reaches for. Your budget tests your plan, not your system — a figure someone wrote in October about a year that hadn’t happened. A hotel missing budget by 6% in a market that fell 12% has a system doing something quite good and a budget doing something quite wrong. Last year tests a different market: beating it tells you this year was better, not that your decisions were, and plenty of hotels beat last year while losing share to the hotel across the street. Keep both as management numbers; stop asking them for a counterfactual they don’t contain.

Baseline 1: read yourself against the market

The least-bad counterfactual available to a hotel is other hotels: a pool of similar properties lived through the same demand and event calendar, so what they did is the closest thing to “what would have happened anyway” that exists. That makes the market indexes the most honest ROI signal you have — MPI, ARI, and RGI, indexed to 100 against your fair share (the 75% walkthrough covers the mechanics).

What matters is the direction of the reading. A falling number can be a win. Take an illustrative 90-room hotel at €120 ADR and 72% occupancy — about €2.84 million a year in room revenue. Suppose the peer pool falls 10% next year and you fall 4%. Every internal number says you lost. Read market-relative, you landed near €2.72 million where falling with the pool would have put you near €2.55 million: roughly €170,000 of separation.

Three limits before that goes in a slide deck: you chose the pool, and a flattering compset produces flattering indexes; a refurbished floor and a new sales hire are in that gap too; and pools lag and shift, so read across quarters. Our own Benchmark works this way — anonymous, opt-in, a three-hotel minimum before any value appears, never a named competitor.

Baseline 2: the floor that needs no counterfactual

Market-relative reading is the best signal, but not the firmest. Underneath sit two things measurable without any alternate reality — and a floor you can stand on beats a ceiling you must argue for.

Time, priced honestly

There is no approved “typical hotel” time saving behind our ROI calculator. It uses editable workflow scenarios: 8–12 hours/week with no tools, 4–7 on OTA dashboards plus spreadsheets, 1–3 on a mature stack and 0–1 with deep analytics, valued at €35/hour across 50 weeks. These are modelling inputs, not observed benchmarks. For the illustrative 90-room hotel, selecting the 4–7 hour scenario produces €7,000–€12,250 a year, with €9,625 at the midpoint. The defensible version starts by timing your own assembly work for two weeks and replacing the preset.

One honesty note: the saving is only real if the freed hours land somewhere useful. Hours moving from building reports to reading them are worth what the reading changes; hours moving to answering email are worth nothing.

Leakage, counted at the decision level

The other measurable is revenue leakage. In the audits we see, decisions a hotel didn’t reach in time can add up to 2–7% of annual revenue — roughly €57,000 to €199,000 a year at this size. Read that as a band for starting a hypothesis, not as your own measured ROI: it comes from other people’s buildings, and nothing about it has been verified in yours. Keep it out of the ROI case. Convert it into dates instead.

An 80-room city hotel makes roughly 25,000–30,000 revenue decisions a year. Say the system moved you on 45 dates last quarter; thirty are too tangled to judge, fifteen aren’t. Fifteen dates that still sold the same 20 room nights each at €18 more comes to €5,400 for the quarter — rooms that demonstrably sold, on dates you can name. Not a counterfactual claim: a floor that compounds.

Baseline 3: judge the dates, not the month

Stop judging the month. Judge the dates the system acted on. A month is thousands of decisions plus a market, averaged into a number that can’t say which part did what. A date is one decision with a visible outcome: did the raised weekends hold their pickup, did the closed-out dates still fill? Two things make that reviewable, and both must exist before you need them.

A dated decision log — written when the decision is made, not reconstructed after the outcome is known. One line: what you changed, why, what you expected, when to review. Reconstructed reasoning is close to worthless, because memory quietly rewrites a decision to match its result. The 5 signs piece treats an unlogged decision as leakage in its own right; a decisions layer exists for exactly this, and the overrides are its highest-information rows.

The ability to replay a decision on the information it had. Judging your March call with June’s knowledge is hindsight, not evaluation. It needs the booking position as it stood in March — a nightly snapshot history, a photo album of your forward position, not a live view that overwrites yesterday. That’s what makes a time machine query possible: “on March 3, what did we know about April?” Many tools can’t, because they never stored it, and your PMS almost certainly can’t either.

Then the question becomes answerable: given what we knew that day, was that a reasonable call? Sometimes a good decision produced a bad night — weather, not failure, the same way you grade forecasts on accuracy trends rather than individual misses.

Quasi-experiments, and what they’re honestly worth

You can’t randomize a hotel, but you can sometimes find a natural comparison. If the system prices transient retail while corporate and group run on negotiated terms, you have something like a treated group and an untreated one in the same building — segment the results and see whether the managed side moved differently. Before-and-after a rollout is the obvious comparison and the most abused: read it same-point and market-relative, or you’ve measured a market cycle and credited it to a purchase.

These are triangulation, not proof. The confounds are mostly invisible: the market shifted mid-test, seasonality doesn’t line up, your team got better while the software did, and — the one nobody admits — you watched the treated half more closely. Treat a quasi-experiment as a vote, not a verdict.

Putting it together: the quarterly ROI review

Two rules: read it quarterly, because a month is mostly noise; and read it as a portfolio, where convergence is the evidence and no single line carries the case.

Instrument it before you switch anything on. This separates hotels that can answer the renewal question from hotels that can’t, and takes an afternoon:

1. Baseline your indexes. MPI, ARI, and RGI for the last four quarters, and freeze your compset definition in writing. You can’t establish a before-and-after once the “before” has passed.
2. Baseline your hours. For two weeks, have whoever assembles the data write down how long it takes.
3. Start the decision log on day one, even before go-live. The pre-rollout entries become your comparison set.
4. Write down what you expect. One dated paragraph: what should improve, roughly how much, by when. The most-skipped step, and the one that makes the review honest — a prediction written in advance can be wrong in a way a story assembled afterward can’t.

Then each quarter, read four things: the indexes versus baseline · the floor, in hours freed at €35/hour and dates you can score · decision quality, by sampling twenty logged decisions and asking how many were reasonable given what was known then · and last quarter’s paragraph, against what happened.

Then the only question that matters: do these point the same way? Three signals agreeing is a defensible case, and defensible is the standard — it’s what every serious capital decision in your hotel already runs on. If they disagree, don’t average them; go find out why. Over a few quarters this gives you a real payback period from your own measured floor rather than a vendor’s average customer, and teaches you to think in incremental revenue.

What overclaiming looks like, ours included

You now have a test for vendor claims. When one promises “+8% RevPAR from our system,” ask how it was measured. A before-and-after measures a market cycle; against budget measures a plan; an average across customers measures other hotels. A precise attributed percentage claims a counterfactual nobody has — including the vendor, including us.

Which obliges us to be straight about our own. We publish an ROI calculator, and it does the very thing this article warns about: it produces a figure before you’ve bought anything. It earns its place, but only with the label attached — it’s a hypothesis, not a receipt. Its ranges are modelling assumptions, not customer proof. Replace them with your own measured baseline as soon as you have one. An estimate made before you owned the software can’t be evidence that the software worked.

That’s the reconciliation, and the point of the piece: the calculator is the estimate; this article is how you test it afterward. Run it before you buy, instrument the four baselines, then check it against reality a year later. If we’re wrong, the method you built will show you — the same standard we’d apply to any AI claim.

Frequently asked questions

How do you calculate the ROI of a revenue management system? Build it from three sources rather than one number. First, a measurable floor: your own recorded hours freed from manual data assembly, priced at a blended staff cost. Our calculator uses €35/hour across 50 weeks and offers an editable 4–7 hour scenario for a hotel moving off spreadsheets and OTA dashboards; that is an input, not a typical-hotel claim. Add the dates where a rate move demonstrably sold the same rooms for more. Second, a market-relative reading — your MPI, ARI, and RGI against a peer pool, the closest thing to a counterfactual a hotel can get. Third, decision-level review: sample logged decisions and judge them on what was known at the time. Read all three quarterly and look for agreement — the result is a defensible case, not a proof.

Can you prove that an RMS increased your revenue? Not in the strict sense, and a vendor claiming otherwise is overselling. The night you priced happened once, so there’s no version of it at the old rate to compare against. What you can do is triangulate: market-relative indexes, measurable time savings, and date-level attribution. When several independent signals agree, the case is strong enough to decide on.

How long before a revenue management system pays for itself? The measurable floor arrives first: once data assembly is automated, compare several weeks of actual time against the two-week baseline you recorded before launch. Price only that measured difference; do not assume a value in advance. Revenue effects take longer, because you need a few quarters of market-relative data to separate your performance from the market’s — expect three to four before anything credible.

Is beating budget proof that the revenue system is working? No, and missing budget isn’t proof it failed. A budget tests your plan — a number written before the year happened. The more useful reading is market-relative: a hotel missing budget by 6% while its pool falls 12% is outperforming, and one beating budget by 3% in a market that grew 9% is quietly losing share.

What should I measure before switching on a new revenue system? Four things, all harder to reconstruct later: baseline your MPI, ARI, and RGI for the last four quarters and freeze your compset in writing; time how long data assembly takes for two weeks; start a dated decision log, even before go-live; and write one dated paragraph predicting what you expect to improve and by how much.

Where to go from here

The Autopilot Flies the Plane owns the no-counterfactual argument, and You Can’t Know the Right Price is its forward-looking twin — there you set a hypothesis, here you grade one. If your revenue management is outsourced rather than bought, the neighboring question is verifying a provider: You Pay for Revenue Management — Can You Verify It’s Working? covers that. For the machinery: Benchmark, Business Intelligence for the snapshot history behind decision replay, the hotel BI guide for evaluating that layer in anyone’s product — including a pricing tool’s — plus the 5-minute self-assessment.

Then do the one thing that makes it work: write down what you expect, and date it. A revenue system is rarely provable. Measured properly, it’s entirely decidable — and an owner who can say “here’s what I expected, here’s what happened, here’s how I know” is in a far stronger position than one holding a vendor’s percentage.