1. Revenue Management System
  2. Features
  3. Demand snapshots
Feature · Demand snapshots

Demand snapshots

Record the observation behind each rate discussion.

OverviewDemand by Stay Date
Revenue Management System · Demand snapshots

Demand by Stay Date

Demand snapshots

New
IdSnapshot dateStay dateUnit typeAvailable unitsBooked units
IDD-62004 Oct07 OctUT-698720580
IDD-56325 Oct15 OctUT-849290310
IDD-87517 Oct15 OctUT-793330770
IDD-60020 Oct15 OctUT-109490950
IDD-79327 Oct15 OctUT-552330320
6 of 6 records
IDD-620Demand snapshots · DS-84969
Snapshot date04 Oct
Stay date07 Oct
Unit typeUT-698
Available units720
Booked units580
Example screen with sample data

What you can do

Capture demand for the stay date

Demand snapshots records when an observation was made, which stay date it covers and the unit type involved. Available and booked unit counts sit beside the competitor rate. Revenue Manager can compare observations over time without treating a competitor quote as an automatic price instruction. Each observation links to a reservation, giving the team an operational case to inspect when reviewing the rate context.

How the work is organized

  • Observation. Demand by Stay Date keeps the snapshot date distinct from the stay date.
  • Inventory. Available and booked counts describe the same unit type at that observation.
  • Rate context. The competitor amount is one input to a reasoned recommendation.

Take a Saturday stay date and record an observation on the preceding Tuesday. The team should be able to explain both dates. Check that counts are nonnegative, the competitor amount is positive and the linked reservation is the intended case. A corrected observation should be recorded as a separate evidence point rather than silently replacing the earlier one. This protects the reasoning behind a later rate review.

What to agree during setup

Decide who supplies the competitor rate and how Revenue Manager identifies the observation date and intended stay date. Keep the unit type spelling aligned with units and rate plans. Require a linked reservation, nonnegative counts and a positive competitor rate before keeping an observation. Agree how to record a correction as a new observation so the earlier evidence remains available for the rate discussion.

Check the handoff on an actual case

Record a Tuesday observation for a Saturday stay, linking it to the intended reservation. Include available and booked units for the stated unit type and a positive competitor rate. Revenue Manager compares it with the existing rate plan before writing a recommendation. Now try a negative booked count and then omit the linked reservation. Each invalid submission should return its precise reason and leave the earlier observation intact. Keep both dates visible when discussing a later rate change with Property Manager.

What your team sees

  • Demand by Stay Date — Shows recorded observations by stay date and unit type.
  • Recommendations Awaiting Review — Shows rate decisions informed by an observation.
  • Unit Occupancy — Shows the stay intervals behind the operating context.

Follow the work through

Walk the linked records in the demand to rate process. Use implementation to agree the first operating cycle and the data model to check the imported references.

What it keeps track of

Data model
Demand snapshots
Daily demand and competitor rate observations for a stay date and unit type.
Reservations
Guest stays with arrival, departure, rate and lifecycle status.
Units
Rentable rooms and suites with capacity and housekeeping status.
Rate recommendations
Proposed nightly rate changes for a stay date, with reason and review status.

Who uses it

Permissions
Revenue Manager
Records observations and explains rate context.
Property Manager
Reviews the resulting decisions.

Set up Revenue Management System your way.

Start free, then use Proto to change fields, steps and approvals before your team goes live.

How to get started