Demand forecast
Every morning a chef answers the same question: how much of what to prep. The buyer answers the neighbouring one: how much of what to order. Usually both answer from memory.
Open Admin Panel → Inventory → "Forecast" tab (admin.cenaly.ru/inventory). The tab takes your sales history and turns it into three concrete artefacts: a prep plan, a supplier order draft, and a list of what risks running out before the day ends. If nothing is at risk, that block is not shown at all.
Available on AWS brands (
cenaly.com,cenaly.ruand others), not oncenaly.ru. The platform's analytical database that computes the sales history for the forecast is not deployed in the Russian contour. The "Forecast" tab does open there, but it always says there isn't enough order history yet — no matter how many sales have actually piled up.
How the forecast is calculated#
Exactly two statistics, both explainable to a chef out loud:
- How much of this dish usually sells on this weekday. The history window is 8 weeks. The point estimate is the median, not the mean: eight Tuesdays, one of which was a 40-person birthday, tell you through the mean to "prep for 40" every week — the median ignores that Tuesday. Next to the number you get the honest observed range (min–max) and the number of observations.
- How that demand is spread across the day — shares by daypart: morning (6–11), lunch (11–16), evening (16–23), night (23–6). The boundaries are the same for every venue.
No machine learning — and that is a decision, not an omission. A venue with one to ten locations has a history measured in dozens of weeks, not years, and outliers punch straight through it: rain, a concert next door, one generous table. Models fitted to such data fit the noise and produce confident numbers you cannot trust.
Fewer than three observations of a weekday means no number. The tab shows "too few" instead. A forecast you cannot trust is worse than no forecast: people prep and buy against it.
The selector at the top chooses the day to forecast — today or tomorrow.
The prep plan#
The dish forecast is exploded through recipes into a need for products and semi-finished items. The explosion uses the current recipes, at the moment you open the tab — if the chef changed a recipe this morning, the plan reflects it.
Nested semi-finished products are exploded fully: if a sauce is made from stock and the stock is itself a semi-finished item, both appear in the plan — otherwise a cook would be told to make the sauce without being told there is no stock for it.
The plan table:
| Column | What it means |
|---|---|
| Product | the semi-finished item to produce |
| Current qty | how much you already have |
| Needed | gross demand for the day from the forecast |
| To produce | the shortfall — what actually has to be cooked/prepped |
| By | the hour stock stops covering demand |
The deadline is not "start of shift". If the sauce covers the morning but not lunch, the cook has to be ready by 11:00, not by 6:00. Rows are sorted by deadline: the earliest first.
Semi-finished stock is spent once: if the same stock goes into both a sauce and a soup, a naive calculation would subtract it twice and the purchase order would come up short.
The "Send to shift board" button turns the plan into a checklist of tasks — see Shift tasks board.
Dishes without a recipe do not enter the plan and are listed in a separate warning: the forecast can say nothing about them, and saying so out loud beats pretending the order is complete.
The supplier order draft#
The second block of the tab is the purchase draft for a chosen coverage horizon ("Cover, days": usually lead time plus a buffer).
For each product two values are computed and the larger one wins:
- forecast need over the horizon minus current stock;
- top-up to the reorder point (par level / minimum quantity) — ordinary stock logic.
Why the larger and not one instead of the other: the reorder point is a safety buffer "so we don't run dry", and it knows nothing about tomorrow's double-booked Friday; while the forecast knows nothing about products that never appear in recipes (packaging, consumables) — for those the reorder point is the only reference. The row shows which of the two rules fired.
Quantities are rounded up to the pack size where one is set on the product. Checked rows turn into supplier orders with one button — from there they are ordinary purchases in Inventory.
"Runs out around 19:00"#
The third block is the run-out risk before the day ends. It compares current stock with the expected consumption over the remaining hours, computed from the daypart profile, and names the hour when stock hits zero.
There is a correction for today's pace: if you have already used more than usual by lunch, the expectation for the rest of the day rises proportionally. The factor is clamped to ×0.5…×2 — a correction for "busy today" is useful, a prediction from a single receipt is not. If there is nothing to measure the pace from, the tab says plainly that the usual weekday profile was used.
What the forecast needs#
| Needed | Why | Without it |
|---|---|---|
A brand on the AWS contour (cenaly.com, cenaly.ru…) |
the sales history is computed by the server-side analytical database, and it only runs there | on cenaly.ru the tab always says there isn't enough order history — a message about history, but the real reason is different: there is nothing to compute it with |
| Sales history | to take the weekday median | the tab says there isn't enough history yet |
| ≥ 3 of the same weekday in history | to have a sample at all | the dish shows "too few" |
| Dish recipes | to explode the forecast into products | the dish lands in the "no recipe" list |
| Up-to-date stock | to compute shortfall and risk | the plan proposes prepping everything from scratch |
The history aggregate is recalculated regularly on the server; recipe explosion and stock subtraction are computed when you open the tab, against current data.
Related sections#
- Inventory — recipes, stock, receiving and purchasing
- Shift tasks board — where the prep plan goes
- Menu engineering — what to do with a dish once you see both demand and margin
- Analytics — sales by dish and period
FAQ#
Why does the forecast say "too few" for half of the dishes?#
Because those dishes have fewer than three sales on this weekday in the history — for example, the dish went on the menu two weeks ago. The number appears by itself once there are enough observations.
Why the median and not the mean?#
The median is robust to outliers. One 40-person banquet shifts the mean enough to make the venue over-prep for weeks. The mean is in the data too — it shows how skewed the history is.
Does the forecast account for weather, holidays, football?#
No. It knows only the weekday and the time of day. A holiday week or a match next door is still the manager's job — and that is more honest than a model pretending it accounted for them.
Can I forecast a week ahead?#
The tab shows today and tomorrow. For purchasing the horizon is set separately — the "Cover, days" field: the one-day forecast is multiplied by it.
Does the purchase draft send the order to the supplier straight away?#
No. It is a draft: you check rows, adjust quantities, and only then create the orders — ordinary purchases in the Inventory section.