Restaurant demand forecasting: where manual planning breaks
Manual restaurant procurement planning and manual shift planning rely on averages: average check over past weeks, average dining hall occupancy by day, familiar write-off norms.
In a flat week, such a calculation holds, but it breaks exactly where a decision costs the most — on peaks and troughs.
The reason is that an average hides the distribution. Two Fridays with the same revenue can have different profiles: in one, the peak falls in the early evening, in the other — in the late evening, and the amount of prep needed for each profile differs.
A manager plans by the number, not by the shape of the curve, so sales forecast errors show up not in the monthly total but in specific two-hour windows.
On top of this come factors invisible in the average: weather, city events, local holidays, delivery promotions, kitchen shift changes.
Individually, each creates a small shift; together they add up to a day where demand is tens of percent above normal — and that is exactly the day when the dining hall and warehouse operate at their limit.
A separate problem is menu interconnectedness. Guests come for a set of dishes, not for "an item in general," so growth in order count changes ingredient consumption disproportionately: one group moves faster, another sits in the warehouse.
The result is predictable: shortages on items with long supply lead times, excess on perishables, growth in write-offs and overtime at peak. Below we break down how restaurant-by-restaurant demand forecasting removes this dependence on one person's experience.
What a forecasting system delivers: impact on procurement, shifts, and write-offs
The effect of the system is measured not by the model's average error but by what changes in operations: how much prep goes to write-off, how many shift hours stand idle, how often an item runs out at peak hour. Below are the results we record with before-and-after measurements.
- Sales forecast accuracy — the share of days where actual deviation from forecast falls within operational tolerance by menu groups grows from double-digit values to 80–90% over a one-week horizon. Importantly, the forecast is built by items and hours, not by total outlet revenue.
- Reduced kitchen write-offs — perishables, prep, and semi-finished products are planned against expected flow by intervals. Write-offs shift from a "constant background" to one-off events: supply defect, breakdown, holiday.
- Shift workload — calculation is based on the forecast for each interval, so the schedule is built around peaks and troughs. Overtime during quiet hours and understaffing in the dining hall go away.
- Day-by-day procurement planning — the supplier order is generated from the forecast taking into account warehouse stock, batch multiples, and shelf life. Procurement stops being "once a week by eye."
- Eliminated failure class "empty shelf at peak hour" — for critical items, the system warns in advance about stockout risk and suggests replenishment or substitution.
- Quality transparency — accuracy is measured daily and visible per outlet. This helps distinguish model error from data failure: overcount, unclosed shift, one-off promotion.
The forecast is built on sales history from the POS loop — most often iiko, r_keeper, or an in-house database.
Forecasting methods: statistics, machine learning model, hybrid mode
The calculation method is chosen not by "advancedness" but by data volume and how much demand depends on external causes.
Statistical sales forecasting — seasonal coefficients, moving average, exponential smoothing: it is stable over a short horizon and does not require labeling, but an atypical week has to be corrected manually.
A machine learning model is connected when there are several outlets and the history includes menu, promo, weather, and dining hall occupancy.
| Option | When it fits | Limitations |
|---|---|---|
| Statistical sales forecast | Single outlet, steady flow, 1–2 week horizon, less than a year of history | Does not see weather, promotions, and local events; holidays are set by manual rules |
| Machine learning model | Chain of outlets, accumulated order history, menu and promo included, horizon up to a month | Sensitive to data quality; accuracy drops when the menu changes or an outlet opens |
| Hybrid forecast | Unstable demand, strong seasonality and holidays, external factors | More expensive to maintain: regular validation, drift control, retraining |
A hybrid forecast is assembled as a statistical base plus a model over deviations: seasonality and holidays are described by explicit coefficients, while the model works with the residual — weather, promotions, local events.
This way a holiday spike is not "smeared" across neighboring days but remains a separate scenario with a clear explanation.
We validate on a holdout period: average error by day and separately for holiday and peak days. If statistics hold 15–20%, while the hybrid reduces it to 8–12%, the transition is justified.
Implementation stages: from sales history analysis to shift operations
Demand forecasting in a restaurant hinges not on the model but on data: sales history mixes takeaway checks, promotions, stop-lists, and manual cashier adjustments.
The work follows a fixed sequence — at each step there is an artifact and a measurable result, so the weak point is visible at the input, not at launch.
- Sales data audit. We export the history of checks and items for the entire available period, reconcile it with the POS and warehouse, and mark gaps, duplicates, and days with promotions or dining hall repairs.
- Forecast calculation scheme. We fix the horizon — shift, day, week — and granularity: item, category, or outlet. We determine external factors: day of week, holidays, weather, local events.
- Model assembly. We train several approaches — from seasonal regression to time-series boosting — and take the one that is more stable on your history, not the one that looks prettier on a chart.
- Forecast quality validation on a holdout period. We calculate metrics and compare against the baseline "average by day of week," separately for fast-moving and rare items.
- Pilot. The forecast runs in parallel with current planning, the manager notes discrepancies with experience — we review them before launch.
- Embedding demand forecasting into the shift. The calculation lives in the operational loop: the forecast for the next day is ready before the shift opens and goes into the manager's report, not a separate file.
- Handover and regulations. We leave the data schema, the retraining procedure when the menu or prices change, and deviation control with notification when the discrepancy is above the threshold.
What we hand over: models, schemas, regulations, and instructions
Handover is not a folder of files but a working loop: the client must be able to launch a forecast recalculation and explain the result without us.
Therefore we fix not only model weights but also how it is structured, what data it was trained on, and where its applicability boundaries are.
- Model documentation: target metric and achieved values on the holdout period, forecast horizon and granularity, which features are used and where they come from, a list of known limitations — holidays, new menu items, supplier change.
- Data flow schema: from POS terminals and warehouse accounting to the feature store and forecast write-back; with quality control points, export schedules, and behavior when data is missing.
- Forecast recalculation regulation: who launches it, in what window, at what frequency; at what discrepancy between actual and forecast unscheduled training is initiated.
- Data access rights: roles and segmentation by outlets, access logging, procedure for granting and revoking access, including a temporary loop for external engineers.
- Team instructions: how to read the forecast and urgent deviations, how to add a new outlet or item, what to do when an export fails.
- Validation and rollback protocol: how to reproduce validation on historical periods and return the previous model version if metrics drop.
- Change log: every edit to features or logic is accompanied by a record — what was changed, why, and how it affected quality.
All artifacts remain in your loop: the repository, tasks, instructions, and access are tied to your accounts, not ours. Support can continue with us, or be handed to your team — the code and documentation are ready for that.
Case of an outlet chain: fewer write-offs and more accurate procurement after launch
How planning worked before
The chain of two dozen outlets purchased products based on managers' experience: orders once a week, volumes by eye with an adjustment for the previous shift.
The forecast lived in separate spreadsheets at each location, no one consolidated discrepancies between outlets, and write-offs and stop-lists were explained by seasonality and human factor.
We collected sales history for each outlet and product category, added a calendar of promotions, local events, and weather data.
The calculation produces demand for a day and a week ahead by item, and the result goes into the accounting system iiko as a draft order — the manager confirms or adjusts it.
What the metrics showed
Forecast error on the daily horizon decreased from 28–30% to 12–14%, and the share of manual edits in orders — from 100% to 18–20%.
Write-offs fell from 7% to 3% of turnover, stop-lists on fast-moving items almost disappeared, and planning time shrank from several hours a week to half an hour.
Stability comes from quality control: nightly reconciliation of forecast with actuals, weekly retraining on fresh data, and an alert when error spikes.
If a new version performs worse, the calculation returns to the previous one — procurement does not depend on how the model performed this week.
How does daily demand forecasting differ from shift forecasting?
Daily forecasting and shift forecasting differ not by algorithm but by horizon and planning unit. The daily procurement plan aggregates demand by item for the next day — that level of detail is enough to form a supplier order and start prep.
Shift forecasting is needed where the decision is made within the day: staffing, station prep, prep for a specific peak.
| Option | When it fits | Limitations |
|---|---|---|
| Daily aggregate | Procurement, supplier orders, daily prep | Does not show where load goes within the day |
| Shift forecast | Staff schedules, tomorrow's assignments | Requires time-stamped check history |
| Hourly load profile | Station prep, peak timing | Sensitive to one-off events and weather |
Within one system, both cuts are calculated from a shared model: the hourly load profile is primary, and the daily forecast is obtained by summing it. If they are calculated independently, the totals do not reconcile — and the planner stops trusting both.
The forecast horizon is chosen by the time during which the decision can still be changed: a supplier order goes out several days ahead, the shift schedule is published a week ahead, prep — the day before. Therefore the model outputs not one number but a set of cuts with accumulation by date.
We measure accuracy separately: the share of days where deviation fell within operational tolerance, and the share of shifts where the forecast withstood the peak hour.
The shift cut is always noisier than the daily one — it is validated not by average error but by hitting the ramp-up hours.
Common doubts before implementing sales forecasting
Sales forecasting hinges not on choosing an algorithm but on data, integrations, and model support. We have collected four doubts that we address before the project starts — with an answer for each.
Sales history is less than a year — will the model not have enough data?
A full year is needed for annual seasonality. Without it, the forecast is built on a weekly profile: days of the week, operating hours, checks by menu category — that is enough for procurement and shift planning, and accuracy grows as data accumulates.
How will the forecast connect to the accounting system?
We read sales and stock from a system of the iiko class or via an export if there is no direct access. We return the result to the same place — as a procurement plan and production task, so the manager stays in the familiar interface and the exchange runs on schedule.
Will holidays and one-off spikes break the forecast?
We mark one-off peaks as events and exclude them from base seasonality — otherwise a one-off banquet will be "learned" as the norm. Such days are calculated as a separate scenario according to the venue's event calendar, rather than pulled toward the average.
Who supports the model after launch?
The menu changes, delivery is connected — the model shifts. We monitor forecast quality and update on schedule, not on complaint; the threshold at which accuracy is considered degraded, and the time to restore it, are fixed at the start.
Let's discuss the task: what we need from you and how the work will proceed
Before the start, a few exports and one responsible person on your side are enough — we will assemble the rest ourselves. Below is what is needed, in what form, and in what order the work proceeds, so you can see the whole plan and stop at any step.
- Sales history: an export from the POS or accounting system by outlet, menu item, days, and hours — the longer the period, the more stable the forecast for each outlet.
- The difference between demand and sales: write-offs, stock, and stop-list rejections. Without them, the model learns from a distorted picture where a shortage looks like low demand.
- Calendar of influences: holidays, promotions, outlet openings and closings, deliveries, and, if possible, weather by cities of presence.
- Menu and substitution reference: how items are connected to each other and what can be considered an analogue when a dish is unavailable.
- Access: data export, test loop or database copy, contact of the person who confirms the correctness of the numbers.
- A person responsible for the subject matter and a feedback regulation — for example, one reconciliation per week: we look at forecast error and decide what to clarify.
The work order goes from data to pilot: first we review exports and agree on the forecast horizon and quality metric, then we assemble and validate the model, then we launch it on part of the outlets and compare with actuals. Only after that do we expand to the whole chain and hand it over to your team.
Describe the task and what you already have in terms of data — we will come back with an estimate, a stage plan, and a list of what is missing for the start.
