In practice6 min read

AI-assisted demand forecasting: keep a forecast-versus-actual journal

A practical journal for small hotels and restaurants: separate forecasts, targets and scenarios, backtest earlier decisions, and preserve forecast errors.

Prepared by the NADALI editorial team using AI

AI illustration: a person compares a conceptual table on a laptop screen with paper records; not a real forecast.
Nadali — reused original AI-generated editorial illustration created with OpenAI image generation · Original AI-generated illustration created for Nadali; use subject to applicable OpenAI terms; no exclusive copyright claim; no third-party input images used. · 1440 × 960

By Nadali. Prepared with AI assistance. Sources checked on 2 November 2026.

A small hotel needs to decide when to review its arrival workload. A restaurant needs to know whether Friday evening may stretch its order-handling capacity. Both can ask an AI assistant for a forecast. The useful question comes later: what did the team know when that forecast was issued, and how different was the eventual result?

Start with a journal rather than an impressive chart. The workflow below is an original Nadali editorial proposal for operational planning. It concerns room use and order counts, not revenue, payments or financial advice. All numbers are invented illustrations, not measured business results.

Give the number a job

Keep three labels visible. A forecast estimates what may happen; a target describes what you want to happen. That distinction is established in the forecasting literature. Hyndman and Athanasopoulos, Getting started.

For this workflow, call a scenario a conditional planning case: “What would we do if the conference ends early?” It need not be the most likely outcome. Never average a manager’s target into the forecast simply to make the two agree.

Write one decision sentence before opening the AI tool: “Every Tuesday at 10:00, estimate occupied rooms for Friday night so the duty manager can review arrival arrangements.” For a restaurant, substitute accepted dinner orders and the relevant service window. Specify whether cancellations count and whether the measure concerns orders, guests or dishes. Use one definition throughout the journal.

Preserve what was knowable

Create a dated input snapshot. Keep the period being predicted separate from the moment the prediction was made. A Monday estimate and a Friday-afternoon estimate for Friday dinner answer different questions, even when they appear on the same chart.

Our suggested snapshot contains historical counts, booking or order information available at the cutoff, opening hours, service interruptions and documented events. Add a plain-language note for each missing period. Do not quietly replace a missing record with zero. Keep original records alongside any corrected version so a later reviewer can reconstruct the calculation.

For a hotel, record rooms unavailable for use and keep booking counts distinct from occupied-room outcomes. For a restaurant, record temporary channel closures. If the business turned customers away, label the outcome as observed activity under a capacity constraint, rather than presenting it as a complete measure of demand. This is a scope note, not a licence to invent the missing customers.

Share only the aggregated operational fields needed for the task. Leave guest names, contact details and payment records out of the working file.

Rehearse an earlier decision

Time-ordered evaluation keeps later observations out of earlier training data. scikit-learn, TimeSeriesSplit.

Choose several earlier decision dates. At each date, use only information available then, issue the same-horizon forecast, and compare it with the later outcome. Repeat forward through time. In our hotel workflow, that means Tuesday-to-Friday each time, not mixing it with same-day forecasts. Exclude events learned about afterwards. If historical booking snapshots were never saved, disclose that limitation rather than reconstructing certainty from today’s database.

Keep a simple comparator: the preceding corresponding weekday’s count. This is a seasonal-naïve baseline, not a claim that last week is always representative. Hyndman and Athanasopoulos, The forecaster’s toolbox.

Separate uncertainty from contingency planning

A prediction interval expresses uncertainty at a stated probability under a forecasting method’s assumptions. It is different from a low/base/high set chosen for planning. Hyndman and Athanasopoulos, The forecaster’s toolbox.

For an illustrative 40-room hotel, a manager might rehearse 24, 30 and 36 occupied rooms. Label those numbers “planning cases”; they have no demonstrated probabilities. Beside each, record one reversible response, its owner and the latest review time. For example, the high case might trigger a review of the arrival desk handover, not an automatic staffing change.

If a tool supplies “80%” beside a range, ask how that range was produced. Do not attach the label to an arbitrary percentage above and below the central estimate. Keep the scenario note and any model-produced interval in separate fields.

Keep the first forecast after the outcome arrives

Here is our suggested journal entry, not a prescribed industry standard:

  • Timing: issued Tuesday at 10:00 for Friday dinner; inputs cut off at 09:00; version v1.
  • Measure: accepted orders, cancellations excluded. Comparator: 110; forecast: 118.
  • Planning cases: low 100, base 118, high 140 orders; no probabilities assigned.
  • After service: actual 126 orders; actual minus forecast +8; actual minus comparator +16.
  • Next question: was the documented group booking available before the cutoff?

The arithmetic in this fictional entry favours the forecast, but one entry proves no general improvement. Mean absolute error averages the sizes of errors without their signs. scikit-learn, Mean absolute error. Compare it across the same dates and units; also inspect signed differences to see which way the estimates miss.

Retain v1 if a later update produces v2. Record who changed it, why, and which new input became available. Score each version against its own lead time. Otherwise, a last-minute revision can erase evidence of an unhelpful early forecast.

Give AI a bounded assignment

Use a prompt such as this original editorial template:

Work only from the attached aggregated snapshot. State the target period, cutoff and unit. Keep the original forecast and the simple comparator separate. Flag missing periods and inputs unavailable at the cutoff. Propose clearly labelled planning cases without invented probabilities. Return a forecast-versus-actual journal structure and questions for the manager. Do not change operating schedules or describe illustrative numbers as measured results.

Have a person approve the input definitions and any operational response. Where a calculation or forecasting model is used, retain its method and version alongside the assistant’s explanation.

At a regular review, examine ordinary days and unusual days separately without deleting inconvenient misses. Ask whether an override improved the decision, whether the forecast arrived in time, and whether the comparison still uses like-for-like periods. Start a clearly marked new series after a material operating change. The journal’s purpose is to preserve learning, including the occasions when a simpler estimate was enough.

The cover is a reused conceptual AI illustration of checking records, not a real forecast or test result. 

Sources and verification

  1. Hyndman and Athanasopoulos — Forecasting: Principles and Practice, Getting started ↗
    Source checked: 2026-11-02
  2. Hyndman and Athanasopoulos — Forecasting: Principles and Practice, The forecaster’s toolbox ↗
    Source checked: 2026-11-02
  3. scikit-learn — TimeSeriesSplit documentation ↗
    Source checked: 2026-11-02
  4. scikit-learn — Metrics and scoring, Mean absolute error ↗
    Source checked: 2026-11-02