A shortfall against forecast is a starting point, not a finding. Split it into guests and average check, then attribute it to a channel by multiplying that channel's share of the day by its own change. Weather is a suspect you cannot test; your own edit to the advertising budget is a suspect you can.
A percentage and an amount say the same thing about size, and nothing about place
Yesterday this restaurant took 18 740 PLN against a forecast of 19 600 PLN. The gap is 860 PLN:
Gap = Forecast − Actual = 19 600 − 18 740 = 860 PLN
Forecast— the revenue the day was expected to produce, PLN;Actual— the revenue the day produced, PLN;Gap— the difference, PLN. Positive means below forecast.
Reverse check: 18 740 + 860 = 19 600. The same gap expressed as a share of the forecast is 860 ÷ 19 600 = 4.3878%, which a dashboard rounds and prints as −4.4% against forecast. Reverse check by the other route: 1 − 18 740 ÷ 19 600 = 0.043878, the same number.
So the percentage and the amount are one fact wearing two coats. Neither of them names an hour, a channel, a table or a decision. Both answer "how big", and the owner already knew the day felt small. A report that stops here has converted a number you can act on into a number you can only feel bad about.
There is one thing the percentage actually loses, and it is worth seeing once.
The true 19 600 sits inside it, so the rounding did no harm here — but the habit does. A percentage carries its base invisibly, and the moment two percentages meet in one sentence, the bases are gone.
Forecast variance — the difference between the revenue a period was expected to produce and the revenue it produced, expressed in currency. The share form of the same difference is a presentation choice, not a second measurement.
Everything below is arithmetic you can do on paper, in the order that narrows the field fastest. It uses one evening of our own numbers, and the same order works on yours.
The first split: guests or the average check
Revenue is a product of two things, and a gap in a product is a gap in at least one of its factors:
Revenue = Guests × Average check
Guests— people served in the period, persons;Average check— revenue per guest, PLN per person;Revenue— persons × PLN per person = PLN. The units cancel, which is how you know the two factors belong together.
The change between forecast and fact then decomposes into three terms:
ΔRevenue = ΔGuests × Check₀ + Guests₀ × ΔCheck + ΔGuests × ΔCheck
Guests₀,Check₀— the forecast values;ΔGuests,ΔCheck— fact minus forecast for each factor;- the third term is the interaction, and it is small whenever one of the two changes is near zero.
Our evening had a normal average check. That kills the second and third terms, and the whole gap lands on guests. To count how many, divide the gap by the check per guest. Our closing report for a full day reads 21 480 PLN of revenue, 126 guests, average check 170 PLN — and those three numbers verify each other: 21 480 ÷ 126 = 170.48 PLN, which rounds to the 170 PLN the report prints. Reverse check: 126 × 170.48 = 21 480 PLN.
That 170 PLN is a different day's figure, and we say so out loud rather than letting it pass as this evening's own. Used as a scale, it puts the gap at 860 ÷ 170 = 5.06 guests. Reverse check: 5.06 × 170 = 860.2 PLN.
Five guests.
Four hundred guests would have meant a different investigation altogether — a power cut, a closed street, a broken booking widget. Five means a channel wobbled.
The trap here is the unit. Guests, covers and bookings are three different counts, and one booking is not one guest. Our own note on the evening says the drop was in seatings from advertising sources, while the advertising report speaks in bookings. You cannot divide one by the other until you know the party size, and if you do not measure party size, say so and stay in the unit you actually have. Mixing the three is the most common way a correct arithmetic produces a wrong sentence. The related distinction between revenue per guest and revenue per bill is a separate calculation with its own denominators.
What the evening's five checks ruled out, and why ruling out is progress
Before naming a cause, the night pass went through the day's other denominators. The value of this table is not what it found; it is what it made impossible.
| What was checked | What it showed | What it therefore rules out |
|---|---|---|
| Evening average check | normal | pricing, discounting, sales mix as the main cause |
| Guests after 19:00 | below usual | nothing — this is where the gap lives |
| Delivery | practically unchanged | a platform outage, a courier failure, a menu error online |
| Google organic | normal | a visibility collapse, a de-listing, a broken site |
| Dinner advertising campaign | 23% fewer bookings | nothing — second place where the gap lives |
Two of the five came back clean in a way that matters. Delivery being flat and organic being normal means the restaurant's demand did not disappear — it failed to arrive through one specific door. That is a much smaller and much more fixable problem than "fewer people want us".
The discipline is worth naming: an explanation that survives is worth less than an explanation that was eliminated. Anyone can produce a plausible story for a small evening. What separates a diagnosis from a story is the list of things you tried to blame and could not. If your report has no such list, it has no diagnosis either — it has a hypothesis with good posture. The wider habit of deciding in advance which numbers a report is allowed to show is covered in reporting automation and the numbers an owner actually looks at.
Why −23% in one channel and −4.4% in the day are the same number
Here is the arithmetic that turns two unrelated-looking percentages into one statement. A channel moves the whole day by its own change multiplied by its share of the day:
Contribution to day = Channel share × Channel's own change
Channel share— that channel's revenue divided by the day's total revenue, a dimensionless fraction between 0 and 1;Channel's own change— the channel's period-on-period change, a dimensionless fraction;Contribution to day— the resulting change in the day, as a fraction of the day. Fraction × fraction = fraction: the units are consistent.
Run it backwards. The day moved −4.3878%, and the advertising channel moved −23%.
In money: 19 600 × 0.190772 = 3 739 PLN.
Read that result carefully, because it is a ceiling, not a measurement. Our own note says the advertising drop was the main contribution, not the only one. If something else took part of the 860 PLN, the channel is smaller than 3 739 PLN, not larger. So the honest sentence is: the dinner advertising channel is worth at most about 3 700 PLN of a normal evening — roughly a fifth of it.
That ceiling does two things at once.
And it sets the size of every decision that follows. Restoring the channel fully is worth up to 860 PLN a day; nothing you do to it can be worth more. If someone proposes a fix that costs more than that, the arithmetic has already answered.
Run the check in the other direction too, because it is the one that catches nonsense. Suppose the channel had really been 200 bookings a night.
When a channel percentage and a day percentage cannot be reconciled by any plausible share, one of the two numbers is wrong — and it is usually the one nobody computed, only quoted.
Rain is a suspect, and it cannot be cross-examined
It rained hard that evening. That is true, it is relevant, and it is the single most dangerous sentence in the whole report — because it explains everything and predicts nothing. Weather has three properties that make it the default culprit in restaurants: it is always available, it is never your fault, and it is never actionable.
What broke the weather explanation here was not scepticism, it was a comparison. Two nearby weeks had comparable weather, and on those evenings the drop was substantially smaller. If rain of that kind cost this restaurant 860 PLN, those evenings should have cost about the same. They did not. So rain may be part of the gap, but it cannot be all of it, and the residue is what the rest of the pass is about.
Similar-day comparison — placing the day in doubt beside days that share its external conditions and differ in the thing you are testing, so that the shared conditions cancel instead of being argued about.
You do not need a meteorologist for this, and you do not need to buy data. Poland's meteorological institute publishes station observations openly. Its synoptic feed returns, per station and per hour, the fields stacja, data_pomiaru, godzina_pomiaru, temperatura and suma_opadu — station, measurement date, measurement hour, temperature and precipitation total. We opened it on 28 August 2026: 62 stations, Warszawa among them. Copy the precipitation column next to your daily revenue for a year and you will own a weather control that no one can argue with, because it is your own city and your own tills.
Once that column exists, the sentence "it rained" stops being an explanation and becomes a filter: show me the other rainy evenings. If they look like this one, weather explains it. If they do not, weather is background and something else moved.
What makes a comparison with similar days honest
The comparison above does the heaviest lifting on the page, so it deserves its own rules. Three of them, and each one has a failure mode you can watch for.
Match on the conditions you are not testing. Day of the week first, because Friday and Tuesday are different businesses. Then anything running that evening: a public holiday, a football match, a street closure, a local event. Then the weather. If you match on a condition that is itself affected by the thing you are testing, the comparison quietly cancels the effect you came to measure.
Choose the comparison days before you look at their revenue. This is the rule people break without noticing. Once you can see the numbers, "similar" starts meaning "similar enough to support what I already think", and the set drifts towards whichever days make the story work. Write the criteria down first, then pull the days.
Count how few days you have. Two comparable evenings are a hint. Ten are an argument. The arithmetic does not change, but what you are allowed to conclude does, and the difference between a hint and an argument is where most restaurant analysis goes wrong. The full method of comparing against a group that did not receive the change is set out in did the promotion work: holdout groups explained, and it is the same logic applied deliberately rather than after the fact.
Note what this method costs you: patience, and the willingness to say "I do not know yet". Both are cheaper than acting on the wrong cause. An intervention aimed at the wrong suspect does not merely fail — it consumes the budget and the attention that the right one needed, and it teaches everyone that analysis does not work.
Official statistics separate season from business, and publish both numbers
If you ever doubt that raw movement needs decomposing before it means anything, look at how statistical offices handle exactly this problem. Eurostat's monthly turnover series for services carries food and beverage service activities as its own activity, and it publishes the same months three times: unadjusted, calendar adjusted, and seasonally and calendar adjusted.
For Poland, activity I56, index 2021 = 100, series updated 27 August 2026 and opened by us on 28 August 2026:
| Month | Unadjusted | Calendar adjusted | Seasonally and calendar adjusted |
|---|---|---|---|
| 2026-03 | 196.8 | 196.8 | 210.0 |
| 2026-04 | 198.5 | 198.5 | 209.9 |
| 2026-05 | 213.1 | 213.1 | 212.5 |
The difference is 7.09 percentage points — points, not percent, because it is the distance between two percentages rather than a change in one.
Reverse check, by the other route: the seasonal factor itself is the ratio of raw to adjusted, 196.8 ÷ 210.0 = 0.9371 in March and 213.1 ÷ 212.5 = 1.0028 in May, a shift of 1.070088. Multiply that by the adjusted growth of 1.011905 and you get 1.082825 — exactly the raw growth of 213.1 ÷ 196.8. The decomposition closes.
Two lessons for one restaurant's evening. First, seven of the eight points of that "growth" were the calendar arriving on schedule, and an owner who read only the raw column would have congratulated the kitchen for May. Second, the unadjusted and calendar adjusted columns are identical here, which means the working-day correction was near zero for these months — the seasonal shape, not the count of trading days, is what moved. Your own version of this correction is the reason a forecast exists at all: the forecast is the seasonal adjustment, done in advance. Comparing today to yesterday is comparing raw to raw. The method behind building that forecast is set out in restaurant demand forecasting, and holding it in a system rather than a notebook is what the forecasting module does.
Your own edit is suspect number one, because it is the only one you can undo
Going deeper into the evening, the pass found that the advertising budget had been redistributed three days earlier, and that the cost per booking had been climbing since. That is the finding, and it outranks the weather for a reason that has nothing to do with how likely each is.
Weather, competitors, the local event calendar and the mood of the city are all real causes and none of them is a decision. Your own changes are a short, dated, complete list — every one of them has a timestamp, an author and an undo. When a metric turns within days of an edit you made, that edit is where you look first, not because it is the most probable explanation but because it is the only one where being right pays and being wrong is cheap.
So keep the list. A dated log of changes to prices, menu, opening hours, staffing, campaigns, budgets and the booking flow costs nothing to maintain and turns "something changed" into "these four things changed, and one of them was three days ago". Without it, every investigation restarts from the weather.
Two more things this particular finding does. The rising cost per booking is a second, independent signal pointing at the same edit: fewer bookings and each one more expensive is what a budget moved into a worse audience looks like. And it tells you which number to watch during the fix — cost per booking, not revenue, because revenue moves for a dozen reasons and cost per booking moves for very few. How to count that cost honestly, channel by channel, is cost per restaurant booking; the wider return on the money is restaurant marketing ROI measured on margin, and the acquisition cost that sits underneath both is restaurant customer acquisition cost.
Three days is thin, and the price of waiting is countable
Three days of post-change data is not much, and pretending otherwise is how a restaurant ends up reversing a decision that was working. Three points cannot separate a real effect from an ordinary bad week, and no amount of arithmetic on three points fixes that.
The mistake is to treat this as a reason to do nothing. Waiting is itself a decision, and it has a price you can put a number on. If the gap repeats, two more days of data cost 2 × 860 = 1 720 PLN. Reverse check: 1 720 ÷ 2 = 860 PLN a day. That is the ceiling on the price of information — the true cost is lower if the gap does not repeat, and zero if the whole thing was rain.
Now the comparison is fair, because both sides are in the same units. Reversing the budget change immediately risks being wrong about the cause and losing whatever the new distribution was worth. Waiting two days risks up to 1 720 PLN and buys certainty. Neither is obviously correct, and that is exactly why a person decides rather than a formula — but the person is now deciding between two priced options instead of between a feeling and a fear.
Cost of delay — the value at risk during the time spent gathering evidence, counted as the per-period effect multiplied by the number of periods you intend to wait.
Three options, and what each one costs
The night pass ends with three, not ten:
A. Restore the previous distribution. Lowest risk. It returns the channel to a state whose performance is known, and the thing being reversed is three days old, so little else has moved on top of it. Its cost is giving up whatever the new distribution might have been building.
B. Keep the current campaign but move part of the budget to a different audience. This keeps the intent of the original change and adjusts its aim. Its weakness is that it changes two things at once — the campaign is already different from what it was, and now the audience is too, so if the numbers recover you will not know which edit did it.
C. Change nothing and collect two more days. Buys certainty at the price computed above.
The recommendation is A. Not because it is the most sophisticated, but because it is the most reversible: it returns the system to a known state, and everything learned afterwards is learned from a clean baseline. B is the option that feels most like management and is the hardest to learn from. C is right when the daily amount at risk is small relative to the cost of being wrong, and here it is not obviously either.
A set of options is well built when it satisfies four conditions, and this one is a fair template:
| Condition | Why it matters | What breaks without it |
|---|---|---|
| Each option is a concrete action, not a direction | "Improve the campaign" cannot be executed or measured | The decision is deferred while appearing to be made |
| Doing nothing is on the list | Otherwise the list forces action for its own sake | The most expensive change is the one made without need |
| Each option has a stated cost or risk | Comparison needs common units | The most confidently argued option wins |
| One is recommended, with a reason | An analysis that refuses to conclude hands the work back | The owner does the analysis again themselves |
Note the fourth. A report that lays out three balanced options and declines to choose has done the easy half. The recommendation is what makes the analysis accountable — if A is recommended and A fails, the reasoning is on the record and can be corrected. Options presented as a neutral menu produce no such record.
Seven places where this arithmetic goes wrong
Every one of these produces a confident sentence and a wrong decision.
Comparing to yesterday instead of to a forecast. Yesterday is a raw number carrying its own day of the week, its own weather and its own events. The forecast is the seasonally adjusted comparison, made in advance. A restaurant with no forecast has no variance to explain, only a series of moods.
Never scoring the forecast. If nobody checks how the forecast performs over a month, "below forecast" may simply mean the forecast is high. A forecast that is never scored eventually explains nothing and blames everything.
Any sentence containing two percentages with different bases needs the bases printed next to them.
Adding revenue to profit. Our own monthly effect table lists nine lines, and they are not one quantity: the revenue lines sum to 8 000 + 15 000 + 4 000 + 5 000 + 8 000 = 40 000 PLN, while profit, cost-equivalent and other lines sum to 5 000 + 3 000 + 10 000 + 2 000 = 20 000 PLN. Those two totals are stated separately on purpose, and a single "60 000" would be a fiction. Not all additional revenue becomes profit, which is why the honest unit for a marketing decision is contribution rather than turnover. A dish that stays in the top three on sales while its contribution falls is a separate calculation entirely.
Mixing a day with a month. The 860 PLN above is one evening. The line "more effective marketing, +8 000 PLN of revenue" in that same table is a month. Neither number becomes the other by multiplication, and a report that puts them in one sentence has invented a third quantity that was never measured.
Stopping at one cause. Rain and a budget change can both be true, and here both probably are. The useful output is not a winner but a split, and a split you cannot compute is still better stated as a range than collapsed into whichever cause is more comfortable.
Where a system helps, and where it does not
Everything above is paper arithmetic. Nothing on this page needs software, and a restaurant that runs the seven-point pass by hand once a week will out-analyse one that owns a dashboard and reads it as a scoreboard.
What a system changes is not the method but the moment. The comparison above needs the day's revenue, its guest count, its average check, its channel split, the campaign's booking numbers, the change log, and a year of weather sitting in the same place at the same time. Assembling that by hand takes an hour, which means it happens after a bad week rather than after a bad evening — and by then three more days have been spent on the wrong distribution.
Ours does the pass overnight and brings a written finding rather than a chart: the gap in PLN, the factor it decomposes into, the channel it attributes to, the eliminated alternatives, the dated change that correlates, three options with their costs, and a recommendation. What it does not do is decide. The budget change is reversed by a person, because the trade-off between a known state and an unfinished experiment is a judgement about the business, not an arithmetic result. That boundary — what runs alone, what runs with a person, what stays with the owner — is set deliberately rather than guessed, and the same evening's staffing call is priced the same way.
The pieces that carry this on our side are the analytics module for the channel split, dashboards for the daily variance, scheduled reports for the written finding, external signals for weather and city events, what-if for pricing an option before it is taken, and the decision engine for holding what was decided and what actually happened afterwards. The last one matters more than it looks: a restaurant that cannot remember which fix worked in May repeats May's argument in September. Guests brought back through the base are counted their own way, and the underlying tree of which number moves which is restaurant KPIs.
Frequently asked questions
Is a 4.4% shortfall against forecast a problem?
By itself it is neither a problem nor a non-problem — it is a size. On this evening it was 860 PLN, which at a 170 PLN average check is about five guests, and five guests is normal daily variation unless it repeats or attributes to something you changed. It became worth acting on only because it attributed to a budget edit made three days earlier, and because the cost per booking was rising at the same time. Score the forecast over a month before treating any single day's variance as a signal.
How do I tell weather from a real cause?
By comparison, not by argument. Pull the evenings with comparable conditions — same day of the week, similar precipitation, no unusual local event — and see whether they show the same shortfall. If they do, weather explains it; if they do not, weather is background and something else moved. Choose those comparison evenings by written criteria before you look at their revenue, otherwise the set drifts towards the answer you already prefer. Poland's meteorological institute publishes station data openly, so the precipitation column costs nothing but the habit of saving it.
What is the fastest first split of a revenue gap?
Guests times average check. If the average check held and the gap is real, the gap is guests, and dividing the gap by the check per guest tells you how many. If the guest count held and the check fell, you are looking at discounting, voids, or a shift in what people ordered — a different investigation with different suspects. Doing this split first stops you from investigating a mix problem that never existed.
How do I attribute a day's shortfall to one channel?
Multiply the channel's share of the day by the channel's own change; the product is that channel's contribution to the day. Backwards, if you know the day moved 4.3878% and a channel moved 23%, the channel's share must be about 19% for it to be the sole cause — which on a 19 600 PLN forecast is at most about 3 700 PLN. Treat that as a ceiling: if anything else contributed, the channel is smaller.
Why look at my own changes before external causes?
Because they are the only causes that come with a date, an author and an undo. External causes are real but not actionable, and they are always available as an explanation, which is exactly what makes them dangerous. A dated log of changes to prices, hours, staffing, campaigns and budgets turns "something changed" into a short list with timestamps, and it is the single cheapest analytical asset a restaurant can keep.
Should I wait for more data or act now?
Price both. Waiting two more days costs at most two more days of the same gap — here 1 720 PLN — and buys certainty about the cause. Acting now risks being wrong about the cause and losing whatever the change was worth. Reversible actions deserve less waiting than irreversible ones, which is why restoring a previous budget distribution is usually decided faster than raising menu prices.
What belongs in an option set for the owner?
Three or four concrete actions, each with a cost or a risk attached, with doing nothing among them and one of them recommended with a stated reason. A set that offers a direction rather than an action cannot be executed or measured. A set with no recommendation looks balanced and quietly hands the analysis back to the person who asked for it.
Take one evening that came in under forecast, split the gap into guests and average check, and write down every change you made in the ten days before it. Most restaurants find the suspect in that list rather than in the weather. The rest of this series lives in the restaurant hub.