Demand

Who this is for: Revenue, Manager, Owner — reading requires rms.analytics.read; running a pass or editing the calendar requires rms.plan.manage. Where: Revenue → Demand

Grain & variance answers what did we sell, at what resolution. Demand asks the harder question: what did we actually face, and what did we turn away?

The difference matters because a sold-out night looks identical to a night that exactly met demand — both sold every room — and they are completely different commercial facts. One of them was underpriced.

Four tabs, each a different part of the same problem: Unconstrained, Outcomes, Calendar, Booking curves.

Unconstrained demand#

When a night sells out or is stop-sold, the sales figure stops being a measure of demand and becomes a measure of your capacity. The demand data is censored — the truth is cut off at the ceiling.

Unconstraining estimates what the night would have sold with no ceiling.

Column	Means
Night · Segment	The stay date and market segment
Sold	What actually sold
True demand	The estimate of what was wanted
Method	How it was estimated
Why censored	What cut the night off

Why censored is the column that makes the rest readable:

• Open — nothing cut it off, so sold is demand
• Sold out (N rooms) — capacity was the ceiling
• Stop-sell on <rate plan> — you closed it yourself

Those last two are very different problems. A sold-out night is a pricing question; a stop-sold night is a decision somebody made, and the estimate tells you what it cost.

Method is either EM or Kaplan–Meier, or Not estimated where there was nothing to estimate from. A row can also carry how many bookings were turned away.

Select Run unconstrained — Run unconstraining — to compute a pass over the window; the tab then reads Estimated as of <date>, so you always know how stale the estimate is. Until somebody runs one, the tab says so plainly rather than showing zeros.

Ghi chú

An unconstrained figure is an estimate and is labelled as one. It never replaces the sold figure — both columns sit side by side, because a forecast built on an estimate should be traceable back to the actual it was derived from.

Outcomes#

Not every booking becomes a stay. The outcome corpus is the record of what happened to the ones that did not — and it is what makes a cancellation or no-show allowance something you measure rather than guess.

A booking enters the corpus once it has resolved: stayed, cancelled, or not turned up. A live booking is in neither the numerator nor the denominator.

Four totals head the tab: Resolved bookings, Stayed, Cancel rate, No-show rate. Beneath them the corpus breaks down by guarantee — Guaranteed, Not guaranteed, Unstated — and by lead band:

Column	Means
Bookings	How many resolved in this slice
Cancelled	The cancellation rate
No-show	The no-show rate
Avg. decided	How long before arrival the decision came

The guarantee split is the useful one. If your not-guaranteed bookings cancel at three times the rate of guaranteed ones, that is the number behind the guarantee flag on a booking — and behind any decision to require one.

Avg. decided is what tells you when to worry. A segment that cancels late is a segment you cannot resell.

Rebuild from history derives outcomes for arrivals that have already happened, which is how a property that has been running for a while gets a corpus without waiting a year.

Calendar#

A history-only forecast cannot see a conference coming. The demand calendar is where the causes go.

1. Select Add event.
2. Give it a name, a start and an end.
3. Choose a category — Holiday, School break, Conference, Concert, Sports, Festival, or Other.
4. Set the expected impact — High, Medium, Low, or Negative.
5. Save.

Quan trọng

You are not asked to guess a number. Expected impact is a coarse expectation — four buckets, one of which is Negative, because a public holiday can empty a business hotel as easily as it fills a resort. The actual multiplier is measured afterwards.

Select Learn impacts once an event has run, and the Learned column fills in from actuals: 1.4x baseline · 3 nights. Until then it reads Not measured yet.

That separation — Expected beside Learned — is the whole design. The first is what you thought; the second is what happened. Keeping them in two columns is what lets a revenue manager find out their instinct about the marathon weekend has been wrong for three years.

Booking curves#

A booking curve is the shape of how a night fills: how much is on the books at each checkpoint before arrival.

Booking-curve profiles are the learned shapes, one per weekday · season · segment — because a Saturday leisure night and a Tuesday corporate night do not fill the same way and averaging them produces a curve that describes neither. Each profile lists its checkpoints as T-30, T-14, T-7 and so on, with the expected share on the books at each and how many samples it was learned from.

Rebuild profiles recomputes them from the nightly on-the-books snapshots — so a property needs the snapshot to have been running long enough to draw a curve at all, which the empty state says.

Pace against the curve is the profiles applied to live nights:

Column	Means
Lead days	How far out this night is
On the books	What is sold so far
Expected share	What the profile says should be sold by now
Projected final	Where the night lands if it follows the curve
Curve shape	On profile, Front-loaded, or Back-loaded

Curve shape is the column to act on. A night that is back-loaded is behind its profile but historically catches up — discounting it early gives away rate you would have got anyway. A night that is front-loaded has already taken the bookings it was going to take, and the pace figure is flattering.

A sample count rides along with each profile, because a curve learned from three peers is a very different claim from one learned from three hundred.

What's next#

• Forecast and pace — the forecast this data feeds
• Grain and variance — what was sold, at what resolution
• Recommendations — where a demand estimate turns into a price
• Reservations — the guarantee flag the outcome corpus splits on