Restaurant Demand Forecasting: Method and Accuracy

Why the manager's memory is already a forecast, and where it stops

A manager who orders three extra crates of tomatoes because "it always goes on the long weekend" has just made a demand forecast. The question is never whether your restaurant forecasts — it does, every single day — but whether the forecast is written down before the day begins.

An unwritten forecast has three properties that make a business hard to run on it. It cannot be wrong on the record, so nobody ever learns by how much it missed. It is not decomposed, so when it does miss you cannot say which part of the reasoning failed: the weekday, the weather or the concert down the street. And it lives inside one head, so the Tuesday manager and the Saturday manager quietly run two different models of the same restaurant.

Demand forecast — a predicted value of covers or sales for a future period, stated together with a range that says how uncertain it is.

Writing it down changes nothing about the kitchen and everything about the argument. A number on paper the day before can be compared with the till at closing, and the difference between those two figures is the only raw material any improvement is ever made from.

Covers, checks, sales or portions: four forecasts that are not interchangeable

"Demand" is not one quantity, and the four candidates behave differently enough that mixing them up quietly wrecks the decision downstream.

Granularity — the smallest unit a forecast is produced for: a day, a day-part, an hour, or a single menu item.

The practical rule is that you forecast the quantity your decision is actually written in. A roster is written in hours, and hours come from sales, so sales is what the roster needs. A supplier order is written in kilograms and pieces, and those come from portions. Forecasting covers and then eyeballing the rest is the step where most of the accuracy is lost, and it is lost silently.

Delivery is a fifth stream and it deserves its own line rather than a share of the dining-room curve. Its weekday shape is different, it reacts to weather in the opposite direction, and it arrives through platforms whose data you receive rather than record — what stays with you in online ordering is about that ownership problem. A single blended forecast across room and delivery averages two rhythms that genuinely differ.

The smallest usable history, and what a monthly total destroys

A forecast is arithmetic on recurrence, so the history has to be fine enough for the recurrence to still be visible in it. A monthly total is the classic loss: once forty thousand złoty is booked as one number for October, no method on earth unpacks it back into the Fridays and the Tuesdays that made it. Day level is the floor, transaction level is better, and neither can be reconstructed after the fact.

How much history you need depends on which rhythm you are trying to predict, and the honest answer is a method rather than a number of weeks. To see a week you need several complete weeks, or the model cannot tell a Friday from a Tuesday and simply averages the two into a number that is right for neither. To see a year you need at least one full annual cycle, because a shorter run does not contain a single complete season to learn from.

That the annual season is real and not folklore is one of the few things Polish official statistics will actually show you.

Read that series for what it is and no further. It is nominal, so part of the climb across any year is price growth rather than extra guests; it is national and covers the whole division, so it contains fast-food counters, canteens and hotel restaurants together; and it describes an industry, not your dining room. It proves the season exists. It cannot be pasted in as your seasonal factor, and this page will not pretend otherwise.

Baseline, day factor, and the double count that hides between them

The workable shape of a restaurant forecast is multiplicative: a base level, then a correction for each thing you know about the day.

Forecast covers = Baseline covers × Day factor × Event factor × Weather factor

• Baseline covers — the level of the period plus its annual season, and nothing else: no weekday profile, no events, no weather;
• Day factor — the weekday profile as a multiplier, computed from your own history as mean covers on that weekday ÷ mean covers on all days;
• Event factor — the multiplier attached to a known calendar or local event, again measured on your own past instances of that event;
• Weather factor — the multiplier for the forecast weather bucket, measured the same way.

Baseline — level and annual seasonality only. The weekday profile is deliberately kept out of it and carried by the separate Day factor multiplier.

That separation is not pedantry, it is the most common arithmetic fault in home-made restaurant forecasts. If your baseline is "the average of the last four Fridays" and you then multiply it by a Friday factor of 1.35, Friday has been counted twice and every Friday forecast is inflated by a third. Baseline is the flat average across all days; the weekday lives in the multiplier; each fact enters the product exactly once.

Worked through with a baseline of 100 covers, a Friday factor of 1.35, a local-event factor of 1.20 and a poor-weather factor of 0.95: 100 × 1.35 = 135; 135 × 1.20 = 162; 162 × 0.95 = 153.9, so 154 covers. Every one of those four numbers is a teaching value. In a real model each of them is measured on your own past days, and a factor you cannot measure is a factor you do not include.

Poland's list of non-working days changed on 1 February 2025, and your history did not

Calendar is the cheapest driver to obtain and the easiest to get quietly wrong, because the calendar itself is legislation and legislation changes. The Polish list of days free from work sits in the Act of 18 January 1951 (consolidated text: Dz.U. 2025 poz. 296, announced 06.03.2025 — the original 1951 wording, Dz.U. 1951 nr 4 poz. 28, is historical and does not contain Christmas Eve), and on 1 February 2025 an amending act added one more entry to it: the Act of 6 December 2024 inserts, verbatim, ka) 24 grudnia - Wigilia Bożego Narodzenia (Dz.U. 2024 poz. 1965, in force from 01.02.2025).

Consider what that does to a model fitted on 2023 and 2024. In that history, 24 December was an ordinary working day; from 2025 it is a statutory day free from work, and offices, schools and the trade around them behave accordingly. The model has learned a fact about the country that has since stopped being true. No error metric will flag this for you, because the model is faithfully reproducing the past it was given.

Driver — an external variable that shifts demand: a holiday, weather, a local event, a payday, a school term.

A payday looks like a private arrangement between an employer and its staff, and in fact a statute pins it into a narrow window. The Polish Labour Code (Kodeks pracy, ELI DU/1974/141) states in Art. 85 that wages are paid at least once a month, on a fixed date set in advance (§ 1); that pay due once a month is paid in arrears, immediately after its full amount has been established and no later than within the first 10 days of the following calendar month (§ 2); and that when the set payday falls on a day free from work, the wage is paid on the preceding day (§ 3) (Labour Code, Art. 85, consolidated text Dz.U. 2025 poz. 277, promulgated 06.03.2025).

For a forecaster those three paragraphs are good news rather than legal trivia, because they narrow the driver instead of blurring it. Pay for the month just ended goes out in arrears and no later than the tenth of the next month, so the payday peak cannot land in the middle of a month: the candidates are a handful of days around the turn of the month, not thirty. The date has to be fixed and set in advance, so a factor measured once does not drift from month to month — and § 1 permits paying more often than monthly, which is why some employers give you two such days rather than one, both of them fixed. The § 3 shift is worth writing into the column explicitly: a payday falling on a Saturday or a Sunday moves to the preceding day, so one Friday a month runs heavier than the rest for a reason that has nothing to do with your kitchen.

What the statute does not do is name the day inside that window — each employer sets its own date. So which day is the fat one on your street follows from who employs people in your district: the offices on one date, the depot on another, the bus garage on a third. The statute sets the window; the employers of your district set the distribution inside it — which is exactly why this factor is measured on your own history instead of being copied out of the code.

The rest of the calendar does not have even that one act behind it. School holiday dates are published per region and per year, and match and concert dates come from the venues. What makes them usable is not their source but their form: each one has to become a column in your history — one row per day, one flag per driver — before it can become a factor. A driver that was never recorded on past days cannot be measured on them, and a factor that cannot be measured is a guess wearing a decimal point.

Testing weather on IMGW station readings instead of believing it

Weather is the driver everyone is most certain about and fewest people have checked. It is also the one where Poland gives you free official data to check it with: IMGW-PIB publishes current synoptic readings and historical observation files at danepubliczne.imgw.pl, station by station, and its live synoptic feed returns temperature, wind, humidity and precipitation per station per hour.

The test itself is ordinary arithmetic. Take a long run of your own days, join each one to the readings of your nearest station, sort the days into a few weather buckets — say, rain against no rain, or three temperature bands — and compare average covers per bucket.

Two conditions without which the weather test measures nothing

First, compare like with like inside the weekday. Warm days cluster in summer and cold days in winter, so a naive comparison of warm days against cold days is mostly a comparison of August against February: you will measure the season, credit it to the thermometer, and then double-count it when your seasonal factor is applied on top. Compare Fridays with Fridays.

Second, keep the covered terrace out of the calculation until you have decided what it is. A venue with outdoor seating has two different weather responses — the terrace opens or it does not — and averaging them produces a single number that describes neither.

If the buckets come out barely apart from each other, that is a result, not a failure. It means weather is not a driver for your venue, your weather factor is 1.00, and you have just removed a source of noise from every forecast you will make.

Events next door: the driver with no official dataset

Local events are the driver with the largest single-day effect and the worst data supply. There is no national register of concerts, matches and conferences you can subscribe to and join to your sales history; what exists is scattered across venue calendars, ticket sites, municipal mass-event notices and the local press.

That leaves two honest options and no third one. Either somebody on your side keeps a calendar — the arena, the two theatres, the conference centre, the stadium, and the recurring market on your own street — and marks each date in the same file as your sales, or you buy that aggregation as a service. This is exactly the job external signals does in our product, and what-if scenarios is where you put the resulting date and ask what the evening looks like if the factor holds.

Either way the requirement is the same as for every other driver: past instances have to be recorded before the factor can be measured. The first big match near your venue is not a forecast, it is a data point. The fourth one is a factor.

Reservations deserve a warning of their own here, because they look like the cleanest demand signal in the building and are not. A book full of tables that never showed up overstates tomorrow, and it overstates it in a way that is invisible unless no-shows are logged as such — the confirmation chain that makes that number trustworthy is set out in our article on restaurant no-shows.

Item-level forecasting, where zeroes are normal and MAPE stops working

Forecasting a dish is harder than forecasting the room, and the difficulty is structural rather than technical. The path through it is the attach rate: forecast covers first, then multiply by the share of covers that historically ordered the item.

What breaks at this level is the measurement, not the method.

That is why item-level accuracy is tracked with WAPE or with plain absolute error in portions, not with MAPE.

Two more traps sit here. A dish taken off the menu for three weeks did not have zero demand, it had no opportunity, and those days have to be excluded rather than learned. And a promotion that ran on eleven days is a driver like any other: recorded, it becomes a factor; unrecorded, it becomes noise that the model spreads evenly across every future Tuesday.

MAPE, WAPE and bias on the same five days: three numbers, three meanings

A forecast without an error measure is just a number you either trust or you do not. There are three standard measurements and they answer different questions, so here they are on one small set of days.

MAPE = (100 ÷ n) × Σ ( |Actualᵢ − Forecastᵢ| ÷ Actualᵢ )

• n — the number of periods compared;
• Actualᵢ — what actually happened in period i, in covers or PLN;
• Forecastᵢ — what was predicted for that same period, in the same unit.

WAPE = 100 × Σ |Actualᵢ − Forecastᵢ| ÷ Σ Actualᵢ

Two legitimate metrics, one dataset, two different numbers — which is the whole reason the label matters.

Bias = (1 ÷ n) × Σ (Forecastᵢ − Actualᵢ)

The signed errors are −12, +9, +8, −14 and +15, summing to +6; divided by 5, bias = +1.2 covers per day. Read the pair together and it says something neither says alone: the forecast is off by about eight percent on a typical day, but it is not leaning. Errors that cancel are random error, and you manage them with a range. A bias of +12 on the same MAPE would be a different illness entirely — chronic over-forecasting, with a roster and a fridge overbuilt every single day of the week.

Why the division has to sit inside the sum

MAPE is the mean of ratios, and a mean of ratios is not the ratio of means.

All three can be printed to two decimal places and all three look equally authoritative. Reporting one of them under the label of another is how two people comparing "our MAPE" end up comparing nothing.

Two properties of MAPE are worth carrying around. It is undefined wherever an actual reaches zero, which is why the item-level section above sends you to WAPE. And it is asymmetric: because the actual sits in the denominator, over-forecasting is punished harder than under-forecasting of the same absolute size. A forecast optimised blindly on MAPE will drift towards under-forecasting, which is exactly the direction that empties a kitchen on a Saturday.

MAPE (mean absolute percentage error) — the average of absolute forecast errors, each expressed as a percentage of the actual value of its own period.

Bias — a persistent tendency to forecast above or below actual. It is a different defect from random error and it is fixed differently.

How much accuracy a roster needs, and how much a Tuesday fish delivery needs

This page prints no sufficient MAPE. Not because the question is uninteresting, but because the sufficient error is set by what your own error costs, and that differs by task inside one restaurant on one day. The general reason none of our pages inherits a circulating benchmark is set out on restaurant prime cost; the specific reason here is simpler still — an error that is harmless for a bag of rice will throw away a box of turbot.

Forecast horizon — how far ahead the forecast reaches. A roster needs days; a supplier order needs at least the lead time, or the number arrives after the decision it was meant to inform.

Read the table as a priority order rather than a scoring system. The forecast that has to be good is the one feeding the decision with the most expensive error, and for most kitchens that is the perishable order rather than the headline daily total.

From the forecast to hours, and from hours to what you dare commit

A forecast that does not change the roster has changed nothing. The bridge is one division:

Roster hours = Forecast sales ÷ Target SPLH

• Forecast sales — forecast covers × your own average check, in PLN;
• Target SPLH — your own target sales per labour hour, in PLN per hour;
• Roster hours — the labour hours the shift may be given, in hours.

With the 154 covers forecast above and a teaching average check of 60 PLN, forecast sales are 9 240 PLN; against a teaching target of 220 PLN per labour hour, that is 42 labour hours for the shift. Where the target itself comes from, and why it has to be built from your own past shifts rather than borrowed, is the whole subject of sales per labour hour. This page supplies the numerator; that one owns the denominator.

The part usually skipped is what the error range does to this division. Run the same arithmetic on the bottom of your range and on the top and you get two hour figures, not one. The prudent roster commits the lower figure and keeps the difference reachable — a short call shift, a split, an agreement with someone who lives nearby.

From the forecast to a quantity on the order, over the supplier's lead time

The second exit from the same curve goes to the supplier, and it has one extra dimension: the order has to cover the period until the next delivery can arrive, not the period until tomorrow.

Order quantity = Forecast usage over lead time + Safety stock − Current stock

• Forecast usage over lead time — forecast portions per day × the supplier's lead time in days, in portions;
• Safety stock — the cushion held against forecast error and delivery slippage, in portions;
• Current stock — what is physically on the shelf right now, counted rather than assumed.

Continuing the same example: 46 portions a day over a three-day lead time is 138 portions; add a teaching safety stock of 40 and subtract 55 portions counted in the freezer, and the order is 123 portions. Note where forecast error enters — it does not change the 138, it sizes the 40. How safety stock and par levels are set, and what turnover they imply, belongs to restaurant inventory turnover.

The step people skip is the last one. An order placed without counting current stock is a forecast added to an assumption, and the assumption is wrong more often than the forecast is.

Costing a miss once, and not twice

Sooner or later someone asks what the misses are worth, and this is the calculation most likely to be inflated — including by people selling forecasting.

Cost of forecast error, when Forecast > Actual: (Forecast − Actual) × Labour cost per cover

Cost of forecast error, when Actual > Forecast: Unserved covers × Contribution margin per cover

• Labour cost per cover — your own fully loaded labour cost divided by covers, in PLN per cover;
• Contribution margin per cover — average check minus the variable cost of serving it, in PLN per cover;
• Unserved covers — the guests you actually could not seat or feed, which is not automatically the whole shortfall.

Over-forecast by 24 covers with a teaching labour cost of 12 PLN per cover: 24 × 12 = 288 PLN of paid hours that served nobody. Under-forecast by 24 covers, of whom you turned away 10, with a teaching contribution margin of 34 PLN: 10 × 34 = 340 PLN of margin that never happened.

The two branches cannot both apply to the same day

A day is either over-forecast or under-forecast. It is never both, so the two results are never added. The temptation to add them is strong precisely because it doubles the number, and a doubled number makes forecasting look twice as valuable as it is — which is why this page states the rule instead of quietly benefiting from it.

The same discipline applies inside each branch. Food thrown away and revenue not earned are usually one event described twice, not two losses; if you count the margin you lost on a guest you could not serve, you do not then also count the ingredients you had bought for them. Count the loss once, on the side where it actually landed, and the resulting figure will be smaller and defensible.

The post-mortem on a day that missed, and what may go into the model

A forecast that missed badly is not a reason to abandon forecasting. It is the one day of the month that contains new information, and the discipline is to write it up in a fixed form rather than to argue about it.

Fill one row per miss and the rules for the last column are short. A cause that is explained and one-off — a burst pipe, a road closed for a day — earns a flag on that row so the model excludes it, and nothing else. A cause that has now appeared three or four times earns a factor of its own, measured on those instances. A miss with no explanation at all earns neither; it goes into the pile that the error metric already counts, and if that pile grows the problem is the baseline, not the drivers.

What must not happen is a new factor per bad day. A model that gains a coefficient every time it is embarrassed ends up fitting its own past perfectly and predicting nothing, and the symptom is easy to spot: error on the days you already know keeps falling while error on next week's days does not move. Keeping that comparison visible from the first day is the point of putting the forecast and the actual on one screen. That pairing lives in the forecast module: comparing the forecast against what actually happened is in its scope from the first day rather than added later. Dashboards and AI reports do something else, and the boundary is worth keeping: a dashboard assembles the company's key indicators — leads, sales, marketing and finance — on one screen, and an AI report sends a weekly summary of leads, campaigns or sales written in plain language. Neither computes a forecast or stands one next to the actual, so looking there for the forecast-and-actual pair ends in disappointment.

What a forecast cannot do, and where machine learning actually sits

Two honest limits, and then the part about our own product.

A statistical model assumes the future resembles the past. Wherever that assumption fails, the forecast fails with it, and no amount of method rescues it: a venue that has not lived through one full seasonal cycle, a business running on one-off banquets with no weekly rhythm, a restaurant in the middle of changing its location, menu or hours, and — the most common case of all — a forecast that nobody uses to place an order or write a roster. The last one is not a modelling problem, and it is the only one on the list a supplier cannot fix for you.

Now the distinction the industry blurs, and we would rather draw. Multiplying a baseline by a set of factors is arithmetic; you have just watched all of it done by hand on this page. Measuring those factors from your own history — the day factor, the weather buckets, the attach rate — is statistics. Machine learning proper begins where the weights are fitted automatically, re-fitted as new days arrive, and chosen by how well they predict days the model has not seen. That is a real difference in method, and it is worth knowing which one you are buying.

In our forecast module the forecast is computed from your own sales history together with seasonality and external signals, it is presented as a number with a range rather than as a single promise, and comparison of forecast against actual is in scope from the beginning rather than added later. That is the statistical layer described above, working on your data. Where a language model is used in the product, it writes up and explains numbers this arithmetic has already produced — it does not produce the number, and our article on which numbers an owner actually looks at is about that same division of labour. Deciding what to do with the number stays with you: the forecast narrows the guessing, it does not take the decision, and it does not remove the need to have a plan for being wrong.

One measured note on where over-forecasting lands physically. Restaurants and food services in Poland generated 293 062 tonnes of food waste in 2023, 8 kilograms per inhabitant, against 4 651 137 tonnes nationally (Eurostat, env_wasfw, reporting year 2023, updated 18.02.2026). That figure counts everything the sector throws out — trimmings, plate waste, spoilage — and nobody has split out the part caused by forecasting badly, so it is not a saving anyone can promise you. It is the size of the bucket that over-preparation drains into, and that is all it is.

Questions restaurant owners ask about demand forecasting

What data does a restaurant need to forecast demand?

At minimum, sales history at day level or finer — a monthly total cannot be unpacked back into weekdays — plus a marker on days that were exceptional for a known reason, such as a closure or a refit. Everything after that is drivers recorded as columns alongside the sales: public holidays, school terms, weather readings, local events. A driver that was never recorded on past days cannot be measured on them, so the recording has to start before the forecasting does.

What accuracy is enough for my roster, and what for my supplier order?

There is no published figure that answers this, and any single percentage offered as the industry answer has no traceable source behind it. The sufficient error is the one whose cost you can absorb, and that cost differs by task: an over-order of rice is cash on a shelf, an over-order of fresh fish is a bin. Work it out per decision — take your typical error, price it with the two branches shown on this page, and compare it against what you would spend to halve it.

What is MAPE and why is it used?

MAPE is the mean absolute percentage error: for each period you take the absolute gap between forecast and actual, divide it by that period's actual, and average those ratios. It is used because it is unit-free, so a day of 90 covers and a day of 400 contribute comparably and the result travels between venues and periods. Its price is two known defects: it is undefined when an actual is zero, and it punishes over-forecasting harder than under-forecasting of the same size.

How do I test on my own history whether weather affects my demand?

Join each past day to the readings of your nearest IMGW station, which are published free at danepubliczne.imgw.pl, then sort your days into a few buckets — rain against no rain, or two or three temperature bands — and compare average covers per bucket within the same weekday. The weekday restriction is what makes the test valid: warm days cluster in summer, so comparing warm against cold across the whole year measures the season and blames the thermometer. If the buckets come out level, weather is not a driver for you and your weather factor is 1.00.

How far ahead should a restaurant forecast?

Far enough ahead of the decision the forecast is meant to change, which means the horizon is set by the decision rather than by the model. A roster needs the forecast before the roster is published; a supplier order needs it at least one lead time ahead, because a number that arrives after the order was placed is a report, not a forecast. Forecasting further out than any of your decisions require adds uncertainty and buys nothing.

Can a restaurant forecast individual menu items?

Yes, and the usual route is the attach rate: forecast covers for the period, then multiply by the share of covers that historically ordered that dish. The two things that change at item level are that genuine zeroes appear, so percentage-based error measures stop working and you switch to WAPE or absolute error in portions, and that days when the dish was off the menu must be excluded rather than learned as zero demand.

How does a forecast become a staff roster?

Through one division: forecast sales divided by your own target sales per labour hour gives the hours the shift may be given. Forecast sales are forecast covers times your average check. Because the forecast carries a range, run the division twice — on the low end and the high end — and commit the lower hour figure while keeping the difference reachable on call. Committing the middle of the range as a certainty is what produces a rota that is overstaffed and understaffed in the same week.

What should I do when the forecast is badly wrong?

Write the day up before arguing about it: forecast, actual, percentage error, the cause if there is a credible one, and what changes in the model. A one-off explained cause earns a flag so the day is excluded and nothing more. A cause that has now recurred several times earns a factor of its own, measured on those instances. A miss with no explanation earns neither and simply stays in the error metric — and if unexplained misses are accumulating, the baseline needs rebuilding rather than the driver list extending.

Want to know how predictable demand actually is in your own venue? Start from your own history rather than from an industry curve: the restaurant guide sets out the neighbouring calculations, automating the restaurant covers where the data comes from in the first place, one screen for several sites covers what changes when there is more than one dining room, and the decision engine is where the forecast, the data and the signals come together as one concrete recommendation, written into a decision journal along with the reason for it. It does not build your roster: the hours come from the division earlier on this page, and the call stays yours.