Revenue · Pricing
How a pricing engine affects your revenue
Dynamic pricing explained for hotels and short-term rentals: demand signals, floors and ceilings, ADR vs RevPAR, common mistakes and a safe rollout.
Streamhost Team4 min read
Most operators set a price for each room type, maybe a weekend rate and a holiday rate, and then leave it alone for months. It feels safe. It's usually expensive.
A pricing engine changes the price of each night based on what's actually happening: demand, how far away the date is, how full you already are, and what's on in town. This guide explains how that works, what it does to your revenue, and how to keep control while a machine suggests your rates.
The cost of a fixed rate
A fixed rate is wrong in two directions at once:
- On busy nights it's too low. You sell out weeks ahead, and the guests who would have paid more book somewhere else, or book your last room at your cheapest price.
- On quiet nights it's too high. The room stays empty, and an empty night earns nothing.
Here's a simple illustration with one unit over a week. The numbers are made up, but the pattern is very common:
| Night | Demand | Fixed rate | Sold? | Dynamic rate | Sold? |
|---|---|---|---|---|---|
| Mon | Low | 250 | No | 190 | Yes |
| Tue | Low | 250 | No | 190 | Yes |
| Wed | Medium | 250 | Yes | 240 | Yes |
| Thu | Medium | 250 | Yes | 250 | Yes |
| Fri | High | 250 | Yes | 330 | Yes |
| Sat | Very high | 250 | Yes | 380 | Yes |
| Sun | Medium | 250 | No | 220 | Yes |
| Week | 4 nights · 1,000 | 7 nights · 1,800 |
The dynamic week doesn't win by charging more every night. It wins because quiet nights get filled and busy nights stop being underpriced.
What a pricing engine looks at
A good engine combines a few signals. None of them is new; the engine just applies them every day, for every night, without forgetting.
| Signal | What it means | Typical effect |
|---|---|---|
| Base price | Your normal rate for the room type | The anchor everything else moves around |
| Day of week | Weekends vs weekdays in your market | Higher on your busy days |
| Lead time | How many days until the stay | Discount close-in gaps; hold rates far out |
| Occupancy | How full you already are for that night | Raise as you fill; lower if you're behind pace |
| Seasonality & events | School holidays, festivals, concerts, conferences | Raise around known peaks |
| Length of stay | Short gaps vs longer bookings | Discounts that fill orphan nights between bookings |
| Min / max limits | Your floor and ceiling | Never below cost, never above what's sensible |
Floors and ceilings are not optional
The single most important setting is your minimum price. It should cover cleaning, laundry, utilities, platform commission and a margin. An engine that's allowed to go below cost will fill your calendar and lose you money.
The maximum protects your reputation. A guest who pays three times the usual rate for an ordinary unit leaves an angry review.
Measure it with the right numbers
Occupancy on its own is misleading: you can hit 100% by giving rooms away. Track these instead:
- ADR (average daily rate) = room revenue ÷ nights sold.
- Occupancy = nights sold ÷ nights available.
- RevPAR (revenue per available room) = room revenue ÷ nights available, or ADR × occupancy.
RevPAR is the number to watch, because it captures both price and occupancy at once. In the illustration above, fixed pricing gives a RevPAR of 1,000 ÷ 7 ≈ 143. Dynamic pricing gives 1,800 ÷ 7 ≈ 257.
Raising prices is easy. Raising RevPAR means pricing each night for the demand that night actually has.
Common mistakes
- Turning it on and walking away. Check the suggested rates against your own market sense for the first few weeks.
- No floor. See above. Set it before anything else.
- Ignoring your real booking data. An engine fed only market data doesn't know your building, your reviews or your repeat guests. Your own booking history is the best signal you have.
- Too many manual overrides. If you override most suggestions, fix the settings rather than fighting the engine one night at a time.
- Forgetting net vs gross. Make sure you compare like with like. OTA commission comes out of the price the guest pays.
Recommendations first, automation later
You don't have to hand over control on day one. A sensible rollout:
| Stage | What happens |
|---|---|
| 1. Capture | Record the real price of every booking from your PMS, so you know your actual ADR and RevPAR today |
| 2. Recommend | The engine suggests a price for each night; you compare it with what you'd have charged |
| 3. Review | After a few weeks, compare recommended vs sold prices and adjust the settings |
| 4. Push | Only once you trust it, let the engine send rates to your channel manager automatically |
Where Streamhost is going
Streamhost already captures booking prices from connected PMS platforms and turns them into revenue reports, so you can see ADR, occupancy and revenue per building without exporting spreadsheets. We're building price recommendations on top of that same data. They'll follow your floors, ceilings, weekend days and seasonal rules, and you'll be able to compare every recommendation with what you actually sold before you let anything change a live rate.
