Hospitality · Demand and distribution

Booking lead time

Booking lead time is the number of days between when a reservation is made and when the guest checks in. It shapes pricing strategy and how to read pace.

Plan your metrics

What it is

Lead time = check-in date − booking date, in days. Report it as a median and a distribution, by stay month, home type, and channel.

Why operators track it

  • Pricing. Last-minute and early demand respond to price differently.
  • Reading pace. If guests book later this year, pace looks behind even when final demand is the same.
  • Minimum stay rules. Gap nights close to arrival are often opened to shorter stays.
  • Channel mix. Channels can differ in lead time.

How it is calculated

Lead time (days) = check-in date − booking created date

  • One value per reservation. Exclude cancelled reservations, or report them separately.
  • Aggregate by stay month (when they stayed) or booking month (when they booked). Pick one.
  • Optionally weight by nights.

Worked example

Example data The same made-up portfolio is used on every hospitality page: a manager with 120 homes, four of them shown in detail.

The four example homes had 22 stays in October. Lead times ranged from 2 to 150 days. The average is 40.7 days and the median is 26.5 days. Five stays were booked within a week of arrival.

October stays by booking window (22 stays)0 to 7 days58 to 30 days831 to 90 days691+ days323%36%27%14%Average lead time = 895 days ÷ 22 stays = 40.7 days. Median = 26.5 days.The average is pulled up by three stays booked more than 90 days ahead. Show the median and the distribution.
Example data Lead time is skewed. The distribution says more than the average.

How to read it

  • Use the median. A few early bookings pull the average up.
  • Compare by stay month. Seasons can book on different timelines. Check your own data.
  • Shortening lead time can mean softer demand or a shift to last-minute channels.
  • We do not publish a benchmark. Levels vary by market, season, and property type.

Definitional choices and common pitfalls

  • Average or median. Median, with the distribution.
  • Weighting. Per reservation or per night.
  • Cancellations. Exclude, or measure separately.
  • Modified bookings. Use the original created date, not the last modified date.

How different roles use it

Role How they use it
Revenue manager Sets pricing and minimum stay by booking window.
Operations Plans staffing for short-notice turnovers.
Product / engineering lead Keeps the original created date even when a booking is modified.

Questions it answers

  • How far ahead do guests book each season?
  • Is lead time getting shorter?
  • Which channels bring last-minute bookings?

How to present it in a report

  • Histogram of lead time buckets by stay month.
  • Median lead time trend by month.
  • Split by channel.
Customer report mockupExample data
Booking windowOctober 2026 stays
Median lead time26.5 days22 stays
Booked within 7 days523%
Booked 91+ days ahead314%
WindowStaysShareRent
0 to 7 days523%$4,250
8 to 30 days836%$9,600
31 to 90 days627%$9,100
91+ days314%$6,200

Data you need

Fields

Field What it means Example value
Created date Original booking timestamp 2026-09-28
Check-in date Arrival 2026-10-03
Status Confirmed or cancelled confirmed
Channel Source Airbnb

What the raw data looks like

Example data A few rows as they might come out of the source system.

Reservation Created Check-in Lead time Channel
R-88412 2026-09-28 2026-10-03 5 Airbnb
R-88470 2026-08-01 2026-10-08 68 Vrbo
R-88533 2026-10-09 2026-10-11 2 Direct

Where this data usually lives

  • Property management system (PMS) holds units, the calendar with block types, reservations, rates, fees, and often owner statements and trust accounting. For example: Guesty, Hostaway, OwnerRez, Track, Streamline, and Escapia. Some larger managers run their own in-house PMS.
  • OTAs and booking channels (Airbnb, Vrbo, Booking.com, and partner distribution sites) hold payout reports, host fees, reviews, and cancellations. Payouts are usually net of host fees.

The same field can live in more than one system. Agree with the customer which one is the source of truth.

Common data gaps and traps

  • Created date replaced on modification.
  • Imported reservations carry the import date instead of the booking date.
  • Time zones. Bookings near midnight shift a day.

FAQ

Why use the median lead time?
Lead time is skewed by a few very early bookings, so the average overstates the typical booking window.
Does lead time differ by channel?
It can. Measure it in your own data rather than assuming.
Should cancelled bookings count?
Usually not in the main figure. Track their lead time separately.
For your data teamFormula variants, tables, SQL sketch, and dashboard spec

Formula details

lead_time_days = check_in_date - DATE(created_at)
median over confirmed reservations by stay month

Worked example detail

Bucket Stays Share
0 to 7 days 5 23%
8 to 30 days 8 36%
31 to 90 days 6 27%
91+ days 3 14%
All 22 Average 40.7, median 26.5

Tables and fields

Table Fields Notes
reservations reservation_id, created_at, check_in, status, channel

SQL sketch

SELECT DATE_TRUNC('month', check_in) AS stay_month,
       PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY check_in - created_at::date) AS median_lead_days,
       AVG(check_in - created_at::date) AS avg_lead_days
FROM reservations WHERE status='confirmed'
GROUP BY 1;

Build spec

Copy this into a ticket. It lists the grain, inputs, logic, and edge cases.

metric: hospitality.booking_lead_time
grain: one row per reservation
inputs:
  - created_at
  - check_in
  - status
  - channel
logic:
  - lead = check_in - created date
  - median and buckets by stay month
edge_cases:
  - negative lead (data error): exclude and flag
  - imports: use source created date
  - cancelled: separate

As a dashboard card

  • Histogram by booking window, with median as the KPI.

Common mistakes

  • Only reporting the average.
  • Using modified date.
  • Mixing stay-month and booking-month views.

Version 1.0 · Last reviewed 2026-10-20 · Machine-readable definition