Signals: Build a Useful Demand Record

Start with the decision and the clock

Before collecting a new feed, write down the decision the forecast will support. A purchasing decision made several days ahead needs a different view from a pre-service briefing. Define the service date, the planning deadline, the forecast horizon and the unit being predicted. “Friday dinner, seated covers, forecast issued on Tuesday afternoon” is a usable specification. “How busy will we be?” is not.

The clock matters because a fair model can only use information available at that deadline. Final reservation counts often look extremely predictive because they include bookings made after the original staffing decision. Store historical snapshots rather than reconstructing the past from the latest booking table. Record both when an event happened and when your system received it.

Separate the events in the guest journey

A reservation records an intention to visit. An arrival records someone reaching the venue. A seated cover records a person served a place. A closed point-of-sale check records a transaction, potentially containing several guests or spanning midnight. These records may be linked, but none should silently stand in for another. Define how split bills, children, complimentary meals and takeaway orders are treated.

Keep separate channels where their workload differs. A delivery order can load the kitchen without occupying a table. A drinks-only walk-in can occupy seats with little food preparation. If the target is seated dining covers, do not add online orders merely because both generate revenue. A model can forecast several targets, but each needs its own consistent definition.

Do not confuse served demand with total demand

Observed covers are constrained by opening hours, table capacity, reservation rules and operational choices. A full dining room does not reveal how many additional guests wanted a table. Similarly, a closed terrace can reduce served covers even when the local market is lively. Record capacity and restrictions beside outcomes so quiet-looking records are not automatically interpreted as weak demand.

Turnaway counts, wait-list entries and unavailable reservation searches can offer partial evidence of unmet demand. They are not perfect measures: one party may try several times, and some people leave without asking. Label the collection method and its limitations. Do not inflate actual seated covers to compensate. Keep realized outcomes and estimates of lost demand as distinct fields.

Build a small, auditable input inventory

A practical starting record includes service date, local service window, seated covers, reservation snapshots, cancellations, no-shows, walk-ins and available capacity. Add a consistent event note for unusual services. Record the restaurant's time zone; Europe/Helsinki and Europe/Paris observe seasonal clock changes, which can complicate interval exports. ISO 8601 timestamps with offsets help distinguish otherwise ambiguous times.

Context can include public holidays, nearby events and weather forecasts. In Helsinki, information from the Finnish Meteorological Institute may be relevant; in France, Météo-France is a possible source. Preserve the forecast as issued, not only the weather eventually observed. A concert listing at Helsinki Music Centre or a trade event at Paris Expo Porte de Versailles is context, not proof of additional restaurant demand. Test its relevance locally.

Check gaps before filling them

Distinguish a true zero from a missing record. A service with no guests is not the same as a failed export. Check duplicated reservations, inconsistent party sizes, changing service labels and abrupt discontinuities after a software migration. Where records are corrected, keep a simple change log explaining the reason. Silent backfills make later model comparisons difficult to trust.

Missing values should retain a reason where possible: closure, unavailable feed, unknown count or not applicable. Imputation may help some models, but it must not erase evidence of an outage. Begin with a completeness report by service and source. An operator should be able to identify which weeks are reliable enough for comparison without reading modelling code.

Collect less personal information

Most aggregate demand tasks do not require guest names, telephone numbers, dietary notes or employee-level tracking. Remove unnecessary identifiers before analysis and set access and retention rules for the remaining records. The GDPR's data-minimisation principle is a useful starting point, not a substitute for assessing your actual legal obligations. Follow source-system terms when exporting or reusing information.

Finish with a one-page data dictionary and a named operational reviewer. For every field, record its meaning, unit, source, refresh timing and known limitations. Ask a host, a kitchen lead and a manager to read the definitions. If they interpret “covers” differently, resolve that disagreement before comparing algorithms. A useful demand record is a shared operating language first and a modelling asset second.