Pace & Pickup Analysis

A forecast tells you where occupancy will land; pace tells you whether you are getting there faster or slower than usual — while there is still time to react. Pace and pickup analysis measures how bookings for a future date accumulate against a historical baseline, turning “we’re 40% booked for next Saturday” into the actionable “we’re 12 points ahead of where we normally are, so hold rate.” This component sits in the Occupancy Forecasting & Demand Analytics pillar alongside Historical Booking Weighting Models and feeds directly into pricing decisions. Without it, a revenue team reacts to final occupancy after the demand window has closed.

Taxonomy and schema governance

The core object is a pickup curve: cumulative rooms sold for a target stay date, indexed by days-before-arrival. Every booking contributes a snapshot keyed by property, room type, stay date, and the lead-time bucket at which it was captured. The baseline is the same curve averaged over a comparable historical set — same day-of-week, same season, adjusted for known events. Pace is the signed difference between the current curve and the baseline at the current reading point, and pickup is the increment between two readings. These definitions inherit the room-type and rate-plan vocabulary from Rate Plan Structuring & Mapping, so a pace figure means the same thing everywhere it is consumed. Validation refuses a non-monotonic cumulative curve (bookings cannot un-happen without an explicit cancellation event) and a reading with a negative days-before-arrival.

Ingestion and normalization

Pickup curves are built from the booking ledger, snapshotted on a daily cadence so each stay date accumulates a time series of readings. Snapshots are idempotent — re-running yesterday’s snapshot reproduces the same point — and cancellations are applied as explicit decrements with their own timestamps rather than by mutating history, preserving an auditable trail. Dates are normalized to the property’s local calendar because day-of-week and event alignment drive the baseline. Comparable-date selection is itself a normalization step: the baseline for a given Saturday is drawn from prior same-season Saturdays, excluding dates flagged as anomalous by Event-Driven Demand Adjustments so a past one-off surge does not distort the norm.

Core implementation

The function below computes pace at the current reading and the incremental pickup since the last reading, from a cumulative series and its baseline.

from __future__ import annotations

import logging
from dataclasses import dataclass

logger = logging.getLogger("forecast.pace")


@dataclass(frozen=True)
class PaceReading:
    days_before_arrival: int
    pace: int          # current cumulative minus baseline cumulative
    pickup: int         # rooms gained since previous reading


def compute_pace(current: dict[int, int], baseline: dict[int, int],
                 dba_now: int, dba_prev: int) -> PaceReading:
    """current/baseline map days-before-arrival -> cumulative rooms sold."""
    if dba_now < 0 or dba_prev < dba_now:
        raise ValueError("readings must move toward arrival (dba decreasing)")
    cur_now = current.get(dba_now, 0)
    base_now = baseline.get(dba_now, 0)
    cur_prev = current.get(dba_prev, 0)
    if cur_now < cur_prev:
        raise ValueError("cumulative bookings decreased without a cancellation event")

    reading = PaceReading(
        days_before_arrival=dba_now,
        pace=cur_now - base_now,
        pickup=cur_now - cur_prev,
    )
    logger.info("dba=%d pace=%+d pickup=%d", dba_now, reading.pace, reading.pickup)
    return reading

A positive pace with slowing pickup is a different signal from a positive pace with accelerating pickup — the first says demand is fading, the second says it is building — which is why the function surfaces both rather than collapsing them into a single number.

Cross-system dependencies

Upstream, pace analysis consumes the booking ledger and the weighting logic from Historical Booking Weighting Models, and it excludes anomalies flagged by Event-Driven Demand Adjustments. Downstream, pace is a primary input to Dynamic Pricing Rule Engines & Optimization: a strong positive pace is exactly the demand signal that justifies holding or raising rate, and it shapes the price-response curves used in Yield Optimization Algorithms. Lead-time context from Lead-Time & Cancellation Forecasting tells the engine how much of the remaining window still matters.

Operational governance

Baselines are versioned artifacts, rebuilt on a schedule and reviewed when their comparable-date logic changes, so a shift in “normal” is a deliberate, auditable event. The daily snapshot job is monitored for completeness — a missed snapshot leaves a hole in the pickup curve that silently distorts pace — and alerting fires on gaps, on non-monotonic curves that slip past validation, and on pace readings that swing implausibly between snapshots. Every pace figure logs the baseline version and the comparable set it was drawn from, so a surprising number can be traced to its inputs rather than argued about.

Troubleshooting and failure modes

Conclusion

Pace and pickup analysis is production-ready when snapshots are complete and idempotent, baselines are versioned and event-aware, and both pace and its rate of change are exposed to the pricing engine. Done well, it converts a lagging occupancy number into a leading indicator a revenue team can still act on.

Related

• Building a booking pace report in Python — a step-by-step build of a pace report from a booking ledger.
• Historical Booking Weighting Models — the weighting approach behind a robust baseline.
• Yield Optimization Algorithms — the downstream consumer that turns pace into a rate decision.