The rate you set on Monday is usually right. It's Thursday's bookings that pay Monday's price.
Saturday is filling faster than it did last year. The update you meant to do on Wednesday moved to Friday, because two people called in sick.
The rate in your sheet carries the date you typed it. The booking carries the date it came in. Nothing in the sheet compares the two. That gap has a name, rate update lag, and it never shows up in a report, because the night still sold.
I'd rather show you the arithmetic than argue about it. The leak report below is a free calculator for independent hotels that price by hand. It turns six numbers you already know into a one-page estimate of what your update rhythm costs a year, without an email address or a login.
Where spreadsheet pricing leaks
Spreadsheet-based rate management loses money in three places. Two of them are about price. The third is about your time.
The rate that was right on Monday
A rate set by hand is only as current as the last time someone looked at it.
Between now and the end of the month you'll update rates about four times, and every booking in between is priced by whoever you were at the last update. Your method is probably sound. You know your rooms, your weekends and the weeks that always fill. The judgment holds up. The calendar is where it slips. In the model, weekly updates leave about half your nights on a rate set before demand last moved. Nothing about your method has to change for that number to shrink. It just has to be applied more often than one person can manage.
The nights you didn't look at
When you update by hand, you update the dates in front of you, and demand on the dates further out moves unseen.
You check next weekend because it's next weekend. The weekend three weeks out, the one filling quietly, waits for a week when things calm down. The weeks that never calm down are the busy ones, and those are the weeks demand is moving fastest. The model counts every unwatched move the same way, as a night sold on yesterday's rate. It can't tell you which nights those were. Your booking pace can.
The hours spent re-keying rates
Every manual update is typed into each channel separately, so the time cost grows with each channel and each update.
A rate change is rarely one change. It's the booking engine, then each extranet, then a check that they all match. By the time the last one is open, another room or two may have gone at the old price. In the model, 45 minutes per update across four channels comes to about 39 hours a year at weekly updates. Move to daily and it's about 274 hours, close to seven working weeks. That trade-off is the real question, and it's where the next two sections go.
How to work out your own leak
This is a simple revenue loss analysis in five steps. Every assumption is shown, and you can change any of them in the report above.
- Room nights sold a year = rooms × occupancy × 365.
- Days between updates: daily is 1, twice a week is 3.5, weekly is 7, every two weeks is 14, monthly is 30.
- Stale-night share = days between updates × share of days your market moves, capped at 1, then halved. Halving reflects that on an average night you are halfway between updates. The model never counts more than half your nights as stale.
- Annual leak = room nights × stale-night share × average rate × pricing error × recoverable share.
- Hours a year = (365 ÷ days between updates) × minutes per update ÷ 60.
| Rooms | Daily | Twice a week | Weekly |
|---|---|---|---|
| 30 | $5,900 | $20,600 | $39,300 |
| 60 | $11,800 | $41,300 | $78,600 |
| 120 | $23,600 | $82,600 | $157,300 |
| Hours a year (any size) | 274 | 78 | 39 |
What this is, what it rests on, what it is not
This is a model of rate update lag, built by Ampliphi. It rests on one principle: a price set before demand moves is the wrong price for nights sold after the move. Published research points the same way. Abrate, Nicolau and Viglia (Tourism Management, 2019) studied 840 hotels in 17 European cities over four weeks in April 2016 and found that hotels whose prices varied more across the booking window earned more. Moving from the first to the third quartile of price variability went with about 3.1% more revenue. That finding is a correlation, and the sample is city hotels rather than independents.
It is not a measurement of your hotel. It does not know your events, your competitors or which nights moved. The leak also stops growing past weekly updates, because of the cap. That is a limit of the model, not good news about monthly updates. Your own booking data replaces every assumption here, and if it says your leak is small, believe it.
Three ways to close the leak, including automated rate management
Update more often by hand
This works, and it costs time. In the model, a 60-room hotel moving from weekly to daily updates closes about $67,000 of its leak and spends about 235 more hours a year doing it. If you have an hour before breakfast service most days, that trade pays. Before you commit the hour, it's worth knowing whether you have it in a busy month.
Set rules in your channel manager or PMS
Some channel managers and PMSs let you raise or lower rates automatically when occupancy crosses a threshold you set. Rules react fast, and they cost nothing to run once written. Their limit is that they only cover the situations you predicted. When the market swings in a way you didn't write a rule for, the rule holds still, and you find out at your next update.
Use automated rate management you approve
Automated rate management reads booking pace and occupancy every day and suggests a rate when demand moves. You see the suggestion and approve it, change it, or leave it. The watching stops depending on how busy your week is, and the decision stays with you.
Handing pricing to software too early feels reckless, and it should. Trust gets built one correct suggestion at a time, which is why approval comes first and automatic publishing is something you switch on later, if ever.
It runs on top of the PMS you already use, so there's no migration project.
The goal is a sentence you can say to the owner on any morning: tonight's rate was looked at this morning, and I approved it.
Ampliphi is revenue management software for independent hotels. It suggests rates based on booking pace and occupancy, prices room types off a single base rate, and the operator approves every rate. Competitor rates and local events are separate views.
Frequently asked questions
How often should an independent hotel update rates?
As often as demand on your dates moves, which a weekly update usually lags. In our model, moving from weekly to daily updates cuts the estimated leak by about 85%, though it costs more hours unless the checking is automated.
Is a spreadsheet good enough for revenue management?
A spreadsheet can hold a sound pricing method. Its limit is that it only changes when someone opens it, so its accuracy depends on how often that happens.
What is rate update lag?
Rate update lag is the time between a change in demand and the next time a hotel updates its rates. Every night sold during that gap is sold at a price set before the change.
How many hours a week does manual rate management take?
It depends on how often you update and how long each update takes across your channels. In our model, a 45-minute update is about 45 minutes a week when you update weekly and about five hours a week when you update daily.
Does automated rate management replace the revenue manager?
It doesn't have to. Pricing automation can do the watching while a person approves each rate, so the decision stays with the GM or the revenue manager.
About this page. Written by Hector Crosswell, marketing at Ampliphi. Last reviewed 2 October 2026.
Sources. The leak model and its assumptions are Ampliphi's and are editable in the report above. Abrate, G., Nicolau, J. L., and Viglia, G. (2019). The impact of dynamic price variability on revenue maximization. Tourism Management, 74, 224-233.
Hector Crosswell leads growth and go-to-market at Ampliphi, the revenue management system for independent hotels. Over a decade in B2B SaaS demand generation, RevOps, and marketing technology, now working directly with the independent operators who run Ampliphi.
View full profile →