In October you printed the rate card: Deluxe at ₹3,500, every night until March. On a Tuesday in February, you sell your last Deluxe for Saturday at that price. A wedding two streets away filled the town three weeks ago. You only find out when the phone keeps ringing with guests you must turn away. This post shows how a pricing engine builds each night's price instead, what it reads, and what stays in your hands.
A fixed rate card is wrong in both directions
A rate card set twice a year makes two mistakes, and only one of them is easy to see.
On busy nights it is too cheap. You sell out early at an ordinary price, and the last rooms go for less than guests would have paid. Selling out feels like success, but selling out is not the same as selling well.
On quiet nights it is too dear. Rooms stay empty at a price nobody was going to pay. An empty room night doesn't carry over to tomorrow: at midnight it is worth nothing.
Worked example
One busy Saturday, one quiet Tuesday
In this example, a 20-room hotel sells every night at a fixed ₹3,500.
- On a busy Saturday, the last 5 rooms sell three weeks early. Guests would have paid ₹4,500 for them, so ₹5,000 is left on the table.
- On a quiet Tuesday, 6 rooms stay empty at ₹3,500. At ₹2,900, four of them might have sold, which is ₹11,600 the hotel never earns.
Neither loss appears on your P&L, which is why a fixed card can feel fine while it costs you money.
What the engine reads before it moves a price
A pricing engine asks one question for every room type and every night: is this night going better or worse than normal? To answer it, the engine reads your own hotel's data.
| Signal | What it tells the engine |
|---|---|
| Rooms already sold for the night | How full you are, for the room type or the whole house |
| Days to arrival | How far out the night is. 60% sold means one thing at 30 days and another at 3. |
| Day of the week | Weekends and weekdays behave differently in most towns |
| Season | Your busy and quiet months |
| Dates you mark | Weddings, festivals, exhibitions and exams you know are coming |
| Pace, if you switch it on | Whether the night is filling faster or slower than this kind of date usually does |
One signal is missing on purpose. ZimmerStack's engine does not look at other hotels' prices unless you connect a source for that. By default, every move comes from your own bookings and your own settings. For more on pace and pickup, read our practical guide to dynamic pricing.
How one night's price is built, step by step
Every price starts from a number you chose. Each step after that adds or takes away a percent, and every step is written down.
- Start from the base rate. This is a price you set for the room type, or the base of a calendar period that covers the night.
- Apply the percent factors. Season, weekday, marked dates and lead time each add or take off a percent. A table of occupancy against lead time adds one more, and pace adds a small nudge if you switch it on.
- Apply your limits. The corridor, the rails and any protected period clamp the price. The tightest limit wins.
- Stabilise. A move smaller than your minimum is held, and no update or day may move the price more than your change budget.
- Round. The price lands on a clean number, such as the nearest ₹50.
- Publish two prices. Channels get the price with your channel markup, and your website gets it with your website discount.
The factors compound, one after another, rather than adding up.
Worked example
One Saturday, three weeks out
In this example, the Deluxe base rate is ₹4,000. The night is 70% sold three weeks before arrival, and it falls on a Saturday.
| Step | Change | Price |
|---|---|---|
| Base rate | ₹4,000 | |
| Occupancy, from your table | +8% | ₹4,320 |
| Lead time | +4% | ₹4,493 |
| Saturday | +6% | ₹4,762 |
| Limits: floor ₹3,200, ceiling ₹4,800 | inside | ₹4,762 |
| Rounded to the nearest ₹50 | ₹4,750 |
If the same night were only 30% sold, your table might say −5% instead of +8%. The price would then come out near ₹4,200.
In ZimmerStack, you can open any night and read how its price was made, step by step, with the numbers. The same night then leaves as two prices, one for channels and one for your website. Why your website must never cost more explains that split.
Your limits always win
No owner hands prices to software that can do anything it likes. The engine works inside fences you set, and it can never publish outside them.
- Corridor. How far a price may move from the base rate, as a percent. For example, 20% either side of ₹4,000 allows ₹3,200 to ₹4,800.
- Rails. Your absolute lowest and highest price for the room type, whatever the corridor says.
- Protected period. A date range where the base rate itself becomes the floor, such as a festival weekend you will never discount.
- Holds. A price you set yourself, for a time you choose. The engine leaves it alone until the hold ends, and it shows as "Set by you" rather than "Automatic".
When two limits disagree, the tighter one holds. You can change any of them whenever you like, and the next update uses the new ones.
A fixed rate card is wrong twice: too cheap on the nights everyone wants, and too dear on the nights nobody does.
Stabilisation keeps prices calm
A price that jumps every hour confuses guests who look twice, and staff who quote on the phone. Stabilisation keeps it steady with three rules:
- A minimum move. A change smaller than this amount is held, not published.
- A change budget. This is the largest move allowed in one update, and in one day, both set as a percent.
- A reversal guard. A price turns back the other way only when the new move is clearly bigger, so one booking can't flip it back and forth.
Every held move is logged, so you can see what the engine wanted to do. New prices go out to your channels within the hour, and again when a booking lands. The same moves reach every rate plan too, because plans follow the base. One base rate for every rate plan shows how.
Choose how much the engine decides
The engine has three modes. You can start in one and move to another as your booking history grows.
| Mode | What moves the price | Good for |
|---|---|---|
| Rules | Only your calendar and your occupancy table. Nothing is learned. | Owners who want every move to follow rules they wrote |
| Assisted | Your rules, plus a small learned nudge inside a narrow band you set | Hotels with some booking history that want a little help |
| Autopilot | What the engine has learned from your history, inside your limits | Hotels with steady history that want the engine to do more |
Any mode can add Review first. Then nothing publishes until you approve it. Small moves can approve themselves under a threshold you set, and the rest wait in a queue with the reason attached. Before a new strategy goes live, you preview exactly which nights would move.
In ZimmerStack, the engine is part of revenue management, included with PMS and Channel Manager from the Growth plan at ₹299 per room per month. It is not an add-on, and it sends prices through the same channel manager as everything else. The revenue management page has a small working engine. Change rooms sold, days to arrival and the weekday, and watch the rate move inside your limits.
Try your own base rate in the pricing labEnter a base rate, plan adjustments, a channel markup and a website discount, and see what each channel and your website would show.Open the pricing labWhat to do this week
- Find last season's early sell-outs. List the nights that sold out more than a week before arrival. Those were priced too low.
- Find the empty nights. List the nights with a third of your rooms unsold. Those were priced too high, or discounted too late.
- Write down your special dates. Mark the weddings, festivals, exhibitions and exams in your town for the next 12 months.
- Set a floor and a ceiling for each room type. Pick the lowest price you will ever sell at, and the highest you are willing to be seen at.
- Move the engine yourself. Change rooms sold and days to arrival on the revenue management page, and watch the rate stay inside your limits.