Start with the decision, not the model.
“Forecast demand” is incomplete. A restaurant may need tomorrow’s item quantities for prep, next week’s ingredient requirement for purchasing, or next month’s revenue for planning. Each decision has a different horizon, granularity and cost of error.
Write the decision as a sentence: By 4 p.m. each day, the kitchen manager chooses tomorrow’s preparation quantity for each high-volume item at each outlet. That sentence defines the prediction date, forecast horizon, entity, user and action. It also reveals which future information is legitimately available at the time.
Start with: “We want to reduce avoidable over-preparation without increasing stockouts for 20 items.”
Choose the lowest grain the decision actually needs.
Outlet-level revenue cannot tell a kitchen how many portions of Chicken Dum Biryani to prepare. Item demand requires outlet × item × service date. Ingredient planning adds recipes and outlet × ingredient inventory. Adding channel or daypart can improve relevance, but only when those fields are complete and the decision uses them.
| Decision | Forecast grain | Common mistake |
|---|---|---|
| Daily revenue outlook | Outlet × day | Forecasting consolidated revenue, then dividing by fixed outlet shares. |
| Preparation plan | Outlet × item × service date | Using revenue as a proxy for portions. |
| Ingredient purchase | Outlet × ingredient × receipt horizon | Ignoring recipe changes, yield and open POs. |
Backtest as if the future were still unknown.
A chronological backtest chooses historical forecast dates, trains or conditions only on earlier observations, predicts the next horizon and compares the result with what happened. Repeat this across ordinary weeks, festivals, closures and volatile periods.
Always compare with simple baselines: previous day, previous week, same weekday average and a recent rolling mean. A more complex model earns its place only when it improves the relevant error measure or produces better decisions consistently.
Accuracy should be reported by outlet and item, not only as one portfolio average. A strong aggregate score can hide systematic under-forecasting for a high-value outlet or unreliable results for sparse items.
Worked example: the next Saturday.
The synthetic Openfluid sample contains 730 days for Jubilee Hills, Gachibowli and Madhapur. Using the previous four Saturdays as a transparent seasonal baseline, the next all-outlet Saturday is approximately ₹168,622 and 281 completed orders.
This is not presented as the best model. It is the baseline that another method must beat. A production forecast should also consider known closures, local events, promotions and current trading signals.
The forecast is only the first half of the workflow.
A preparation recommendation needs a service buffer, batch rule and holding-life policy. A purchase recommendation needs usable stock, open supply, lead time and pack size. These belong in a governed decision layer, not hidden inside the demand model.
Capture whether the operator accepted or changed the recommendation. The reason (booking, event, weather, equipment problem or local knowledge) is valuable context. Later, compare the original forecast, recommendation, override and actual outcome separately.
Know what the source cannot tell you.
POS sales are censored when an item is unavailable: zero sales after a stockout does not mean zero demand. Sales also do not reveal how much was prepared or discarded. The model needs availability, preparation and waste records to answer those questions responsibly.
External events may not repeat in the same way. Historical festival uplift, discount response or aggregator promotion should be represented as known future information only when the comparable event is actually planned.