When Dynamic Pricing Doesn't Work
Automated pricing needs demand history, real variation, and enough bookings to learn from. The property types where it underperforms, and what to do.
Dynamic pricing — moving your room rate by date in response to demand, instead of holding a fixed seasonal rate — underperforms when the data underneath it is thin, when demand barely varies, or when your bookings do not repeat in a pattern you could learn from. Seasonal resorts with a twelve-week season, ferry-access islands, markets running 30% occupancy, and houses that are mostly group business are the honest failure cases. In those situations a careful person with a spreadsheet and a local events calendar usually does as well. This post is the list of when to walk away.
What automated pricing actually needs
Three things, in order of importance.
Repetition. Something that happened before and will happen again — a Friday that always fills, a shoulder season that always sags. Patterns are the raw material.
Variation. Demand has to move. If every night of your year looks the same, there is nothing to respond to and a flat rate is the correct answer.
Volume. Enough bookings that a week of data means something. Three reservations is not a signal, it is noise.
Take away any one of the three and the machine is guessing more confidently than you are. That is worse than guessing.
Case 1: your season is too short to learn from
A resort open sixteen weeks a year generates roughly a hundred trading nights. Five years of history is still only about five hundred nights, spread across weather, school holidays, and whatever the exchange rate did.
Compare that to a city hotel, which produces 365 nights a year and repeats the same weekly rhythm fifty-two times. The city hotel accumulates a usable pattern in a single year. The seasonal resort may never accumulate one.
What to do instead: price the season, not the night. Build three or four rate tiers by how full the season is running, review weekly against last year's same week, and put your effort into the two or three peak weekends where the money actually is.
Case 2: you are running at 30% occupancy
At 30% occupancy, price is not what is stopping people from booking. Nobody is choosing a competitor over you because you are $12 too expensive on a Tuesday in February. They are not looking for a room in your town at all.
Cutting the rate in that market moves almost nothing. Cornell's Canina and Carvell studied 480 hotels over eleven years and put the price elasticity of lodging demand at −0.14 — a 1% rate cut produced only about a 0.14% increase in demand. Demand tracked income and the wider economy, not room rates.
What to do instead: fix demand before you fix price. Distribution reach, direct channel, photography, review scores, and a reason to visit will each do more than a pricing engine at that occupancy level.
Case 3: your demand is one-off, not repeating
Some properties live on demand that arrives once and never returns in the same shape — a wedding venue, a hotel next to a single annual festival, a stopover property serving one construction project.
An automated system reads last year's festival week and prices this year's accordingly. But the festival moved venue, the lineup is weaker, and the organizer released 4,000 fewer tickets. The pattern was never a pattern. It was a coincidence that happened twice.
What to do instead: treat those dates as manual overrides on a calendar, priced off the actual event facts — attendance, dates, whether attendees stay over. Let anything automated handle the ordinary nights and keep the exceptional ones under your own hand.
Case 4: groups are most of the house
If half your room nights come from blocks negotiated months in advance, transient pricing — individual bookings taken at your public rate — is only governing part of your inventory. Worse, the group block distorts the signal. The system sees a night filling fast and pushes rate, when what actually happened was a fifty-room wedding block landing at a contracted rate.
What to do instead: separate the two. Decide how many rooms you will protect for transient demand on each date, and price against that smaller number. Group rate negotiation is a displacement calculation — what would those rooms have earned otherwise — and it is a human conversation, not an algorithm.
Case 5: the model was built on a hotel unlike yours
This is the failure operators feel but struggle to name. A pricing model shaped by urban business-hotel demand expects a Monday-to-Thursday peak, a weekend trough, a 20-to-40-day booking window, and near-zero length of stay variation. Point that at a coastal resort with Saturday peaks, a six-month booking window, and a seven-night average stay, and the recommendations will look bizarre — because they are answers to a different question.
What to do instead: ask directly what property types the system was built and tested on, and what it does when it has no history for a date. A straight answer is a good sign. A deflection is also information.
Where it works and where it struggles
| Situation | Automated pricing | Why | Better first move |
|---|---|---|---|
| Year-round hotel, 55%+ occupancy, steady weekly rhythm | ✅ Works well | Repetition and volume both present | Automate the routine, keep events manual |
| Urban property with frequent events | ✅ Works well | Demand varies sharply and often | Event calendar plus rate rules |
| Seasonal resort, 12–20 week season | ⚠️ Limited | Too few observations to learn a pattern | Season tiers reviewed weekly |
| Market running under ~35% occupancy | ❌ Poor fit | Price is not the constraint | Demand generation and distribution |
| Group-dominated house | ⚠️ Limited | Blocks distort the demand signal | Displacement analysis by hand |
| One-off destination demand | ❌ Poor fit | The pattern is not repeatable | Manual overrides on known dates |
What the evidence actually says
Here is the part most vendor content leaves out.
The percentage RevPAR lifts you see quoted for revenue management systems — and you will see several, all confident, all different — come from vendor marketing, not from independent research. We do not repeat them, because we cannot trace them to a study anyone can read.
What does exist is a single peer-reviewed academic study of revenue management system adoption (Ortega, B., 2016, International Journal of Contemporary Hospitality Management 28(4), 658–680). It found that adopting hotels improved occupancy more than rate, and found no statistically significant RevPAR effect. That is the honest state of the evidence.
The stronger evidence in this field is about pricing behavior, not software. Cornell's analysis of 67,008 hotel observations from 2001 to 2007 (Enz, Canina & Lomanno, Competitive Hotel Pricing in Uncertain Times, Cornell Hospitality Report Vol. 9 No. 10) found hotels priced 20–30% below their comp set ran about 15 points more occupancy and about 12% lower RevPAR. Pricing discipline pays. The authors themselves note the data shows correlation, not causation.
So: the discipline is well evidenced. The software is not — at least not publicly. Anyone telling you otherwise is selling.
The mistakes on both sides of this argument
Buying because the market says you should. "Everyone has an RMS now" is not a business case. If your demand does not vary, you are automating a decision that does not need making.
Refusing because you got burned once. A model that misread your resort is evidence about that model, not about the method. The occupancy ladder underneath it still works.
Automating the exceptional nights. The handful of event and holiday dates that carry your year deserve a human. Automate the ordinary ones and buy yourself the time to think about the rest.
Assuming low occupancy is a pricing problem. It usually is not. Check your reach before you check your rate.
Not asking what the system was trained on. It is the single most useful question in the purchase conversation, and almost nobody asks it.
The bottom line
Automated pricing rewards repetition, variation, and volume. Where all three exist it removes tedious work and catches dates you would have missed. Where any one is missing — a short season, a dead market, one-off demand, a group-heavy house — a person with a spreadsheet and a local events calendar does the job, and the honest advice is to keep doing that.
If your situation is on the "poor fit" side of that table, the useful thing is usually not automated pricing at all. It is simply seeing what the hotels around you are charging, day by day, without spending an hour a morning on it — which is what a comp-set view is for. Pricing stays your decision.