Skip to main content
A revenue manager dashboard is the daily working surface for the people who set rates and watch inventory. It needs three things at a glance: headline metrics that summarise the upcoming window, a per-day calendar of availability and pricing, and a way to drill down on restrictions. One Daily Rates call powers all of it.

Prerequisites

Before building the dashboard, make sure you have:
  • A working Daily Rates call. If not, follow the Quick start first.
  • A hotel ID and a group ID for the property you display.
  • A target window (typically 30 to 180 days, depending on the team’s planning horizon).

How it works

The Per day endpoint returns availability, prices, and restrictions for every day in your window, grouped by rate plan, hotel, and entity. Each entity is one room and rate combination. Daily fields come back as { value, start, end } segments, with an exclusive end date: a single segment when nothing changes, multiple segments sharing their boundary dates when the value moves across the window. A dashboard slices that response three ways:
  • A headline metrics block (total available room-nights, average daily rate, closure rate) to give the revenue manager the shape of the window in one glance.
  • A calendar grid of (date, room) cells, with status, availability, and price, for day-by-day investigation.
  • A restrictions overlay on the grid, surfacing minimum-stay and closure flags so the team knows why a day looks the way it does.
All three views are computed from the same Daily Rates response.

Build the dashboard

The examples below assume the OAuth signing setup from the Quick start.
1

Request the visible window

Call Per day once with the dates the dashboard shows and a layout that includes the operational fields. For a back-office surface, request Status, Availability, TotalPrice, MinimumStayOnArrival, and the closure flags.
2

Pivot segments into per-day cells

For each entity, walk every temporal segment and emit one cell per (roomId, date) pair. Carry the operational fields onto the cell so both the metrics block and the grid can read them without a second lookup.
3

Compute the headline metrics

Aggregate the per-day cells into the dashboard’s KPIs. Three metrics cover most revenue-management views:
  • Available room-nights: sum of availability across cells where the room is open. Tells the team how much capacity is up for sale across the window.
  • Average daily rate: mean of totalPrice across cells where the room is open. The pricing pulse of the window.
  • Closure rate: share of cells where status is not Available, or closedOnArrival / closedOnDeparture is true. A high number signals heavy restriction pressure.
4

Render the grid with operational cues

Display each room as a row, each day as a column. The cell value combines availability count and price; the cell colour signals status. Use the on-arrival restrictions for tooltips so revenue managers see why a day looks the way it does.
5

Refresh on demand

A revenue manager dashboard is a working surface, not a published page. Refresh on tab focus or on an explicit reload action so the team always sees the latest snapshot. Keep a short cache (one to two minutes) for navigation responsiveness, but invalidate it the moment the user takes an action that should change the grid.

Tips

  • Compute KPIs from the same payload. The metrics block and the grid both read the per-day cells produced in step 2. One pivot, two views, no extra call.
  • Pivot once, render many times. The grid is cheap to re-render across filter changes (room subset, status filter, date sub-window). Build it once per refresh and slice in memory.
  • Show segment boundaries. Where a price changes mid-window, the API returns two segments. Surface the boundary visually in the calendar (a thin separator, a colour shift) so revenue managers can spot rate changes at a glance.
  • Cap the window. 30 to 180 days is plenty for an operational view. Longer windows are slow and rarely useful, since data this far out drifts before revenue managers act on it.
  • Keep restrictions in the tooltip, not the cell. The cell shows price and availability. Hover surfaces the restriction reason. A grid that tries to render every restriction inline gets unreadable fast.

Reference

Full schema for the Per day endpoint.

Best practices

Caching, performance, and resilience patterns.