Evening Forecast: From “It'll Be Busy” to a Priced Decision

A forecast you can neither accept nor refuse is not a decision

At 17:00 our system looked at today and found four things at once: 74 bookings on the book, good weather, an event in town, and a history of raised walk-in after 21:00 on days that follow such an event. The staffing had been built for an ordinary Friday.

Every one of those four facts is true, and all four together still produce nothing a manager can act on. "It will be busy tonight" cannot be accepted, declined, delegated or measured afterwards. It has no addressee, no deadline and no price. A month later nobody can say whether it was right, because nothing was decided.

What we sent the manager instead was this:

There is a raised probability of evening load. It makes sense to extend shift X by 90 minutes. Estimated additional payroll: 54 PLN.

That sentence has an addressee (the manager), a subject (one shift), a size (90 minutes), a price (54 PLN) and exactly two possible replies. It can be refused, and refusing it is also a decision — a recorded one, with a known price on the other side.

The cost of a decision — the money the business spends if it says yes, expressed in the currency it pays in and attached to the request itself, not to a later report. Without it the request is a warning; with it the request is an option.

This page is about the conversion between the two. The arithmetic is small on purpose: all of it can be done on paper by a manager who never buys a single piece of software.

The four signals of this evening, and what each one is actually worth

The four signals are not equal, and treating them as one lump is the first mistake.

74 bookings is a fact of the book: countable, already ours, the only one of the four that carries names and times. It tells you the floor of the evening, not its ceiling — a booked table is a table you already know about.

Good weather and an event in town are external conditions. Neither is a number of guests. They are reasons to expect the unbooked part of the evening to behave differently from an ordinary Friday, and by themselves they change nothing on the rota.

Historically raised walk-in after 21:00 following such an event is the only one of the four that measures our own past. It turns the two external conditions into an expectation, because it says what happened here, in this room, the last times the same conditions lined up.

That is the order of trust: the book, then our own history, then the outside world. An event in town is a hypothesis. Our own record of what such an event did to the room after 21:00 is evidence. The method for building that record — how many past days you need, how you compare like with like, how you avoid reading noise as a pattern — is the subject of demand forecasting.

The signal that changes the rota is the last one

Bookings do not change the rota, because staffing was built with the booking curve in mind. Weather does not change it either, because weather is not a headcount. What changes the rota is the expectation of unbooked guests arriving in a window when the rota is already thinning out — and that expectation only exists because the same pattern was recorded before.

This is also why the decision goes to the manager and not to the owner: one shift, one evening, a price of one lunch. The split between what a system does alone, what it does with a person, and what stays with the owner is a design choice that has to be made deliberately; we take it apart in three levels of system autonomy.

What “+18 % above base” tells you, and what it hides

That number is honest and it is also, on its own, unusable. A percentage is a ratio, and a ratio without its denominator is not a quantity:

Extra guests in the window = Base guests in the window × Uplift

• Base guests in the window — the number of guests you normally serve in that window on a comparable day, in guests;
• Uplift — the expected excess above that base, a dimensionless share (0.18 for 18 %);
• Extra guests in the window — the result, in guests.

The dimensions close: guests × dimensionless = guests. The arithmetic is trivial. The problem is that the base is not on this page and cannot be: it lives in your point-of-sale, cut to the hour, for days comparable to this one.

Baseline — the number the percentage is measured against: the same hour, the same weekday type, the same conditions, taken from your own records. A forecast expressed only in percent hands the reader a number he cannot act on until he supplies the half you kept.

So the honest statement of what we knew is: the shape of the evening was clear, the size of it was known only to the room. That is precisely why the decision had to be priced in money rather than in percent. Money is the one unit in which a manager can compare an unknown-sized upside with a known-sized cost.

Keep both, but in their places. The percentage belongs in the explanation of why the request appeared; the zloty belongs in the request.

The window comes first, the shift second

The window is 21:00 to 22:30. The shift ends at 21:00. Those two facts, and nothing else, produce the 90 minutes:

Extension = Window end − Shift end

• Window end — the hour at which the raised flow is expected to stop, clock time;
• Shift end — the hour the person is scheduled to finish, clock time;
• Extension — the result, in minutes of one person's time.

22:30 − 21:00 = 1 h 30 min = 90 minutes. Reverse check: 21:00 + 90 minutes = 22:30, which is the end of the window we started from.

That looks like a triviality. It is not: the 90 minutes were not chosen as a round number, a habit or a compromise. They are the window. Coverage falls out of the same two facts:

Coverage = Extension ÷ Window length

90 ÷ 90 = 1.00, that is 100 %. Reverse check: 1.00 × 90 = 90 minutes. The extension covers the whole of the forecast window and not one minute more.

If you take one habit from this page, take that one. Size the response to the window, not to the shift. A manager asked to "stay a bit longer" will stay an hour, because an hour is what people mean by a bit longer — and the last thirty minutes of the window go uncovered while the first thirty minutes of the extension are paid for nothing. The window is a measured thing; "a bit longer" is not.

Two ways to be wrong about the window: ending it too early, because the tail of an evening always feels like it needs nobody, and rounding its start to the top of the hour out of tidiness. Both are cheap to avoid — the window comes from your own hourly counts, the same source as the baseline. Table turnover tells you how long a wave of arrivals occupies the room after it stops arriving: the window of work is longer than the window of arrivals, and the difference is the average time a table is held.

The price of the decision: what falls out of 54 PLN

The estimated additional payroll for extending the shift by 90 minutes is 54 PLN. That is the whole of what we told the manager, and it is enough to decide. But it also contains one more number, and that number is worth pulling out because it is the one you will reuse:

Rate per hour of extension = Additional payroll ÷ Extension in hours

• Additional payroll — the estimated extra payroll caused by the extension, PLN;
• Extension in hours — the length of the extension expressed in hours, dimensionless count of hours;
• Rate per hour of extension — the result, PLN per hour.

54 PLN ÷ 1.5 h = 36 PLN per hour of extension.

The reverse check, by a second route

A single division is exactly the kind of arithmetic that goes wrong quietly, so it is checked twice, and the second check goes a different way rather than repeating the first.

Forward: 36 PLN/h × 1.5 h = 54 PLN — the original figure comes back. By minutes: 54 PLN ÷ 90 min = 0.60 PLN per minute, and 0.60 PLN/min × 60 min/h = 36 PLN/h. The same answer arrives without ever converting 90 minutes into 1.5 hours, so a slip in that conversion could not survive both routes. Dimensions close on both paths: PLN ÷ h = PLN/h, and PLN/min × min/h = PLN/h.

Now the rate is portable. The next request for the same person is priced by multiplication instead of by asking payroll: 60 minutes is 36 PLN, 30 minutes is 18 PLN, two hours is 72 PLN. A manager who knows one rate can price four decisions before the shift starts.

What the 54 PLN is, and what it is not

The 54 PLN is our estimate of the additional payroll caused by this extension. It is not the employee's gross wage for those 90 minutes, not the fully loaded cost of an hour of work in a restaurant, and this page does not turn one into the other. The conversion from a gross rate to a fully loaded hourly cost runs through employer contributions whose rates differ by employer, and there is no single multiplier that does it — so we do not print one. If you need that number for your own restaurant, what a labour hour costs as a share of sales sets out which components belong in it.

Two consequences, both practical: do not compare our 36 PLN/h with a wage rate — they are different quantities and the comparison says nothing. Do compare it with itself over time: the rate implied by extensions of the same person on the same position is a stable number in your own books, and a jump in it means something changed in the rota, not in the arithmetic.

Turning any forecast into a priced decision: four steps

Nothing above is specific to Friday evenings. The same conversion works on a delivery running late, a review score sliding, a supplier price moving, a phone line filling at lunch. Four steps, in this order:

1. Name the window. From what hour to what hour, in clock time. Not "this evening", not "the weekend". If you cannot name the window, you do not have a forecast — you have a mood.

2. Name the resource the window is short of. One position, one person, one oven, one phone line. Forecasts fail as decisions most often here: "we'll be busy" does not say what runs out first. On a busy Friday it might be the floor, the pass, or the line that answers the phone — and how many calls you can pick up in the peak hour is the same calculation on a different resource.

3. Name the unit in which the resource can be added. 90 minutes of one shift. One extra person from 19:00. One more line for two hours. The unit has to be something a manager can order into existence today, not a capability the business would need a month to build.

4. Price that unit, and put the price in the same sentence as the request. Not in an appendix, not in a weekly report. In the sentence. A price that arrives later is a report about a decision already made blind.

The test that tells you the conversion worked: the person receiving the message can answer yes or no, and knows what he has just spent. If he has to ask "how much is that", step 4 was skipped. If he has to ask "for whom, exactly", step 2 was skipped.

Why the price has to be in the message and not in a dashboard

Because the message is read at 17:00, in a corridor, on a phone, by someone who is about to be busy. A dashboard where the number could be found is not the same thing as a number that was brought. That is the whole difference between a system that reports and one that decides — reporting that shows the numbers an owner actually looks at is the same idea applied one level up.

What the extension has to earn back

A priced decision invites the obvious next: how much does the evening have to bring in for 54 PLN to be worth spending? The revenue answer is easy and half true. The average check that evening was 170 PLN, so:

Break-even in average checks = Cost of the decision ÷ Average check

54 PLN ÷ 170 PLN per check = 0.32 of one check. Reverse check: 0.32 × 170 PLN = 54.4 PLN, back to the starting figure within the rounding of the ratio; carried to four places, 0.3176 × 170 = 53.99 PLN.

Dimensions: PLN ÷ (PLN per check) = checks. So in revenue terms the extension pays for itself if it results in roughly one third of one additional average check across the whole 90 minutes.

That is where the easy answer stops being useful, because revenue is not what pays for payroll.

Contribution margin — the money left from net sales after variable costs, available to cover fixed costs and, once they are covered, to become profit. That definition belongs to our page on the break-even point, and it is the number the comparison actually needs: an additional check does not hand you 170 PLN, it hands you what remains after the food, the packaging, the card fee and the hourly labour that moved with it.

So the true threshold is stated in contribution, not in revenue:

Break-even in guests = Cost of the decision ÷ Contribution per guest

Dimensions: PLN ÷ (PLN per guest) = guests. The formula is complete; the input is not ours to supply. Contribution per guest is a property of your menu, your channel mix and your daypart, and this page will not print a number for it: we do not have one for your room, and inventing one would be worse than leaving the line open.

What we can say without any borrowed number is the size of the bet. That evening closed at 21 480 PLN of revenue, so:

Share of the day = Cost of the decision ÷ Revenue of the day

Reverse check: 0.0025 × 21 480 PLN = 53.7 PLN, and at four places 0.002514 × 21 480 = 54.0 PLN. Dimensions: PLN ÷ PLN = dimensionless share.

A quarter of one percent of a day is the size of the thing being decided. Naming that share is part of pricing the decision: it tells the manager how much attention the choice deserves, and the answer here is little — decide it and move on.

The forecast can be wrong, and the two errors do not cost the same

This does not appear in the message we sent, and it should be said plainly, because it follows from our own numbers even though nobody wrote it down.

The forecast may not come true. The event ends early, the crowd goes somewhere else, and the 90 minutes are paid for an evening that behaved like an ordinary Friday. The cost of that error is known exactly: 54 PLN.

The opposite error is a service failure at the peak: the surge arrives, the room is short a person for 90 minutes, waits get longer, tables turn slower, some guests leave without being served and some who were served will not come back. That error costs more than 54 PLN. How much more, we cannot tell you — that number does not follow from our data, and we are not going to invent it.

That second cost is a real quantity in principle: lost covers, contribution not earned, a slower turn on tables that were already booked, guests whose next visit does not happen. Each is measurable in a restaurant that measures it. None of them is in the numbers this page stands on, and a figure assembled here to make the comparison look complete would be exactly the kind of confident invention that is worse than an admitted gap.

So the honest shape of the decision is asymmetric:

Asymmetry is not an argument for always saying yes. It is an argument for naming which way you are wrong when you are wrong, and for putting the bounded cost where the manager can see it. A decision whose downside is a known 54 PLN and whose upside is an unquantified avoidance is still one he is entitled to refuse — and now he refuses it knowingly.

Asymmetric cost of error — a decision where the two ways of being wrong differ in size, in visibility or in when they arrive. In these decisions the cheap, visible error gets over-managed and the expensive, invisible one gets ignored, simply because one of them has a number on it.

What the closing report proves, and what it does not

It is tempting to read that as the verdict on the 17:00 decision. It is not, and refusing that reading is the difference between measuring and telling yourself a story. The report does contain two useful things.

First: it can be checked against itself

Average check = Revenue ÷ Guests

21 480 PLN ÷ 126 guests = 170.48 PLN per guest, and the report says 170. Reverse check: 126 × 170 = 21 420 PLN, 60 PLN short of 21 480 — the gap is the rounding of the average check to whole zloty, and 60 ÷ 126 = 0.48 PLN per guest, exactly the fraction rounded away. Dimensions: PLN ÷ guests = PLN per guest.

That takes fifteen seconds and is worth doing on every report you receive, from any system. A daily report whose three headline numbers do not reproduce each other has a fault upstream, and the arithmetic finds it before the month does.

The same trick reconstructs the forecast the report compares itself to:

Forecast = Actual ÷ (1 + Deviation)

21 480 PLN ÷ 1.057 = 20 322 PLN. Reverse check: 20 322 × 1.057 = 21 480 PLN.

So 20 310 to 20 330 PLN, and no more precision than that is real.

Second: it cannot attribute the surplus

The day beat its forecast by about 1 158 PLN — 21 480 minus the reconstructed 20 322. Against a decision that cost 54 PLN, the surplus is roughly twenty-one times the cost, and that ratio is not the return on the decision. Writing it down as one would be false in three ways: the forecast the day beat was made before the 17:00 signals were read, so part of the surplus is the very surge the extension answered; nothing in the report separates money earned in the 90-minute window from money earned in the other ten hours; and no comparison exists to an evening where the same signals appeared and the shift was not extended, so the counterfactual is missing entirely.

The way to actually answer "did it work" is a holdout: the same decision taken on some comparable evenings and deliberately not taken on others, with the difference measured across a run rather than on one day. That method, its sample sizes and its failure modes are the subject of testing whether a promotion actually worked, and it applies to staffing decisions unchanged.

Meanwhile the closing report earns its keep for a different reason: it is short. Everything that behaved normally is absent from it, and the manager did not spend ninety minutes assembling it.

Where this is a system, and where it is plain arithmetic

The boundary is not where most people assume, so state it directly.

Plain arithmetic, no system required: every calculation on this page. 90 minutes from two clock times. 54 divided by 1.5. 54 divided by 170. 21 480 divided by 126. Reconstructing a forecast from a percentage. All of it is division, and all of it fits on a napkin.

Statistics you can do by hand but usually will not: the base flow in the 21:00–22:30 window on comparable days, and the size of the walk-in lift on days after an event in town. This is counting rows in your own sales history and cutting them by hour. Any owner can do it; almost nobody does it every day, and doing it once a quarter is not the same thing.

What software actually contributes: speed and the absence of forgetting. The four signals were read at 17:00, on the day they mattered, while the rota could still be changed — not at 23:00 when the evening is history. Our forecasting and scenario modules do the counting, decision support turns a counted number into a priced option, team holds the rota and tasks is where the accepted decision becomes something with an owner and an end. The wider shape of that arrangement is described in an AI restaurant management system.

What is neither: the judgement. Whether 54 PLN is worth spending on a probability is decided by a person who knows things the numbers do not carry — that this member of staff has an early start tomorrow, that the room is already one cook short. The arithmetic exists to make that judgement cheap, not to replace it.

Doing this by hand, on one sheet of paper

A manager with a notebook and yesterday's sales report can run the whole of it. Five lines, in this order:

1. The window. From your hourly sales for comparable days: when the late wave starts and when it stops. Two clock times.
2. The base. Guests in that window on those days, averaged. One number, in guests.
3. The expected extra. Base × the lift you have recorded for these conditions. Never recorded a lift? Write "unknown" — a truthful entry that stops you dressing a guess as a forecast.
4. The unit of response. Which person, which position, from what hour to what hour. Minutes, not adjectives.
5. The price. Minutes ÷ 60 × the hourly cost of that person. One multiplication. Put it in the message.

Then the two questions that close it: what does it cost if I do this and nothing happens, and what breaks if I do not do it and it does happen. The first has a number. The second usually does not — knowing which is which is most of the skill.

Keep the sheets. Twenty of them are a record of which conditions produced a surge and which did not, and that is the only way the third line ever stops saying "unknown". A restaurant that keeps them for a season has built its own forecast, on its own room, with no data source but its till. The same discipline applied to bookings that never arrive is the confirmation chain against no-shows; the same measure applied per seat and per hour is RevPASH, which tells you whether the extended 90 minutes were worth a seat's time at all. To express the whole thing in one ratio, sales per labour hour puts the extension in the denominator and the evening in the numerator.

Two more of the same shape, worth naming because they happen on the same evening: why revenue dropped in the evening is this method run backwards on a day that missed its forecast, and a shift that takes too long to close applies it to the hour after the last guest leaves. And an evening decision is never one decision alone — what analytics is supposed to answer is which of them deserve a number at all.

Frequently asked questions

Why 90 minutes and not a whole hour or a whole shift?

Because the window was 90 minutes. The forecast covered 21:00 to 22:30, the person was finishing at 21:00, and the difference between those two clock times is the extension. Rounding up to two hours would pay for 30 minutes outside the window; rounding down to an hour would leave half the window uncovered. The length of the response is a measured quantity, not a courtesy.

How do you get 36 PLN per hour out of 54 PLN?

By dividing the payroll estimate by the length of the extension in hours: 54 PLN ÷ 1.5 h = 36 PLN/h. The check runs by a different route: 36 × 1.5 = 54, and separately 54 ÷ 90 minutes = 0.60 PLN per minute, which is 36 PLN per hour. Both routes give the same rate, so a mistake in converting minutes to hours could not hide in either.

Is 36 PLN per hour the employee's wage?

No, and treating it as one would be a mistake. It is the rate implied by our estimate of the additional payroll for this extension — nothing more. It is not a gross wage, and not the fully loaded cost of an hour of work, which includes employer contributions that vary between employers. This page does not convert between those quantities, because that needs a multiplier we do not have.

What if the evening turns out quiet and the extension is wasted?

Then the decision cost 54 PLN, 0.25 % of that day's revenue, and the cost was fully known in advance. The opposite mistake — not extending on an evening where the surge does arrive — costs more, but our numbers do not say how much more, and we are not going to put a figure on it. That asymmetry is the actual content of the decision.

Does “+18 % above base” mean eighteen more guests?

Only if your base for that window happens to be a hundred guests. A percentage is a ratio and needs its denominator: extra guests equals base guests in the window multiplied by 0.18. The base comes from your own hourly counts for comparable days, and it is the half a forecast expressed in percent leaves out. This is why the request that reached the manager was denominated in money.

The day closed 5.7 % above forecast — does that prove the extension worked?

No. The surplus is about 1 158 PLN against a 54 PLN decision, and that ratio is not a return. The day's forecast was made before the evening signals were read, the report does not separate the 90-minute window from the other ten hours, and there is no comparable evening where the same signals appeared and the shift was not extended. Answering "did it work" needs a holdout across several evenings, not one good night.

Can a restaurant do this without any software?

Yes, and it should be able to — otherwise the arithmetic is being hidden rather than done. Five lines on paper: window, base, expected extra, unit of response, price. What a system changes is not the calculation but the hour it arrives: 17:00, while the rota can still be altered, every day, without anyone remembering to ask.

The other pages in this section take the same room apart from other angles — how the evening is forecast, what an hour of labour costs, what a table is worth per hour. Start from the restaurant hub and take the number that hurts most this week.