Ten Locations: How 100,000 Events Become Three Decisions

Ten venues do not add attention, they add layers

One venue is held together by looking at it. The owner walks the floor, hears the phone, sees the delivery arrive, and the loop between an event and a decision is short enough that nobody has to write it down.

At five, ten or thirty venues that loop breaks for an arithmetic reason rather than a managerial one. A person has a fixed number of hours and a fixed number of things he can hold in his head at once; events scale with the number of rooms, tables, phones, suppliers and shifts. So the only thing that can be scaled is the number of people between the event and the owner — and that is exactly what a chain of ten venues buys.

For ten restaurants the chain used to look like this:

Count the links and then count the gaps between them, because they are different numbers and it is the second one that matters:

A management layer — a place in the chain where information is received, summarised and passed on, rather than where the event itself happens.

Six handovers is not a criticism of anybody's work. It is a statement about what necessarily happens to a signal, and all three effects are honest work:

• it delays the signal, because the receiving person has their own day and their own queue;
• it compresses it, because nobody forwards everything — a report is a selection;
• it re-frames it, because the person passing it on is judged on their own numbers, and a summary written by someone with an interest in it is not the same object as the event.

So the owner of ten venues does not receive a thinner version of what the owner of one venue receives. He receives a different object: an aggregate, six removes away, of things already selected five times. An eleventh venue makes the aggregate wider without making it closer.

This is where most people go looking for a dashboard. A dashboard fixes the compression and does nothing about the delay or the re-framing, because a chart still needs a person to look at it, decide it matters and act. Which numbers an owner actually looks at is a separate piece; what one screen across several venues can and cannot do is another.

The alternative is not a better summary. It is a filter that decides, per event, whether a human is needed at all.

Four buckets: what the sort of 100 000 events actually says

Across the ten venues we sorted 100 000 events for a month, and the sort came out like this:

Three checks before this table is worth anything.

Check one — the buckets are exhaustive. 99 650 + 327 + 20 + 3 = 100 000. If they do not add up to the total, some events were classified twice or not at all, and every share below is wrong.

Check two — the shares add up. 99.650 + 0.327 + 0.020 + 0.003 = 100.000 %. Run it in the other direction as well: 100 000 − 327 − 20 − 3 = 99 650.

Check three — the human total. Everything that reached a person at all is 327 + 20 + 3 = 350 events out of 100 000, or 0.350 % of the month. That is the number worth carrying around, not the three.

Events per owner decision = Total events ÷ Owner decisions

• Total events — every recorded occurrence in the period across all venues, count;
• Owner decisions — events the filter routed to the owner, count;
• result: 100 000 ÷ 3 = 33 333.33 events per decision, and the reverse check 3 × 33 333.33 = 100 000.

An event is not a problem, and this is where the table is easiest to misread. A confirmed booking is an event. A supplier's message is an event. A closed checklist item is an event. Ninety-nine and a half thousand of them needing nothing is not a sign of a quiet month; it is a sign of a normal one.

An event — one recorded occurrence with a time, a source and a venue: a sale, a message, a call, a booking, a shift task, a stock movement, a review, a payment. It becomes management work only when a rule says so.

What a rule is made of: a condition on data plus an addressee

A filter is not a mood. It is a finite list of rules, and every rule has exactly two halves.

A rule — a condition stated over data the business already records, plus the addressee the event goes to when the condition holds.

Miss either half and the rule is useless in a specific way:

• a condition without an addressee produces an alert nobody owns, which is how a business ends up with a notification channel everyone mutes;
• an addressee without a condition produces "tell me if anything looks odd", which is the layer we were trying to remove, wearing a new name.

The addressee is one of exactly four, and they are the four buckets above:

The three working modes behind those addressees — what the system does alone, what it does with a person, and what stays with the owner — are a separate page in this wave. What matters here is that the boundary is written down in advance. A boundary decided event by event is not a filter; it is a person deciding, which is the thing being replaced.

You can do this on paper. Take one venue and one week, list every category of thing that happened, and next to each write the condition under which you would want to know and who would act. That is a filter. It will be short and wrong in places, and both are fine: the shortness tells you how few rules cover most of the traffic, and the wrongness is what the next week corrects.

Four worked rules, one per bucket

Rules are easier to trust when you can see the numbers inside one. Here is one rule per addressee, each drawn from an ordinary day.

To nobody. A supplier's item is running two hours late. The delivery lands at 13:40; current stock covers service to roughly 14:25. Stock outlasts the delay, the risk of a stop-list is low, no action is required. The condition is arithmetic — stock runs out later than the delivery arrives — and the owner never sees the event. The full calculation of stock against consumption is worked through on its own page.

To the system or to staff. Forty-five minutes before opening, the summer terrace has not been confirmed ready. The system asks the person on shift, the person answers "ready", the system records it. If no answer comes, it asks again, and nothing escalates unless the second ask also fails. This bucket holds most of the 327.

The shape of that condition is worth copying: the same deviation, on the same step, in a majority of a defined number of recent repetitions. One late closing is weather; seven out of eleven is a process. What the fix looks like is a page of its own.

That number alone is not a decision — three days earlier the advertising budget had been redistributed, and reverting it, moving part of it or waiting two more days have different consequences. The event reaches the owner because the options differ, not because the deviation is large. Separating weather from your own change is the whole of that page.

All four conditions are stated over something the venue already records — stock, a checklist answer, closing timestamps, takings against forecast. That is the practical test of a rule you are about to write: if it needs data you do not collect, it is not a rule yet, it is a project.

The largest bucket is a remainder, not a measurement

Here is the sentence that ought to make an owner uncomfortable, and it comes straight out of the arithmetic above.

The three small buckets are counted: 327 events matched a rule with a system or staff addressee, 20 matched a rule addressed to management, 3 matched a rule addressed to the owner. Someone or something looked at each of them.

The big bucket is not counted. It is what is left: 100 000 − 350 = 99 650. Nothing inspected those events. They are in that bucket because no rule fired on them.

That is why the honest name for the bucket is not "needed no attention". The honest name is the remainder.

The remainder — the events on which no rule fired. It contains two different populations that no number in the table can tell apart: events that genuinely needed nothing, and events that needed something for which no rule exists.

This is the difference between "we checked and it was fine" and "we did not check". Both produce the same figure, and the second produces it more cheaply. Any report showing you a large calm bucket is showing you, in the same breath, the part of the month nobody looked at.

The practical consequence: the number to watch over time is not 99 650, which is dominated by ordinary traffic and will always be large. Watch the rules — how many exist, how many fired this month, how many fired zero times. A rule that has never fired is either describing something that never happens or is written wrongly and cannot fire at all, and from the outside those two look identical.

The event that has never happened has no rule

Now the boundary itself, stated as plainly as we can.

Every rule in the filter was written from something that had already happened. Closing running long was findable because there were eleven comparable shifts. A stock risk is computable because consumption has a history. A takings deviation is measurable because there is a forecast, and there is a forecast because there are previous months.

An event that has never occurred has none of that. No threshold to breach, because nobody knew what to measure. No comparable set, because the set has one member. No forecast, because forecasting needs repetition. So no rule fires — and the event lands, silently and correctly by the filter's own logic, in the remainder.

This is not a defect to be patched; it is the shape of the method. Rules generalise from repetition, and the first instance of anything has no repetition behind it. Anyone who tells you a classifier covers events it has never seen is describing a wish.

What can be done about it is smaller than the problem, and worth doing anyway:

• Keep a slot for the unclassified. Some events can be flagged simply for being unlike anything else — a message fitting no category, a payment matching no pattern, a shift behaving unlike its own history. That is a weaker signal than a rule and it produces false alarms, which is the price of covering a first instance.
• Treat the first instance as a rule-writing event. When something novel surfaces — through a guest, a member of staff, an accountant — the fix is two things: handle it, and write the condition that would have caught it. Otherwise the second instance lands in the remainder too.
• Ask the people, because they see what the data does not record. A driver always twenty minutes late, a table nobody wants, a regular who stopped coming and told a waiter why — none of that leaves a row anywhere. No filter reads it. A manager does.
• Say out loud what the filter does not cover. A written list of "things we know we are not watching" is worth more than a longer list of rules: it is the only document that makes the remainder visible.

That last one is the honest version of this whole page. A filter that leaves an owner three decisions is a good filter. A filter that leaves an owner three decisions and cannot say what it is not looking at is a story about a good filter.

Three is a setting of the filter, not a property of the month

The second thing the number three does not mean.

Three is the count of events that matched rules addressed to the owner. Change a rule and the count changes with the month untouched.

Require a majority of eleven shifts and the closing pattern reaches management; require a majority of five and it reaches them three weeks earlier, more often, and sometimes wrongly.

So the number is a property of the settings first and of the business second. That is not a flaw — it is the control you actually have — but it changes how the number should be read.

A falling count of owner decisions is ambiguous. It can mean the business became more predictable. It can equally mean a threshold drifted, an integration went quiet, or a rule stopped matching after a menu or supplier changed. The same figure describes improvement and blindness: silence and health look alike, exactly as in the remainder.

So the count has to be read next to something. Two things work. Read it against the count of rules that fired at all — if decisions fall while firings fall across the board, suspect the plumbing, not the business. And test it deliberately: change one threshold, recount the month, see how far the number moves. If halving a band triples the owner's queue, the three was mostly about the band.

This is also the honest answer to "how many decisions should reach me?" There is no published norm, in this sector or any other, and we went looking. The number is chosen. What can be defended is not the number but the rule behind each escalation: this event reached you because the options in front of you have materially different consequences, and here they are. An escalation that cannot be defended in that sentence is a notification, and notifications belong to the layer we removed.

Nine rows and three different units: how to read the effect table

The organisational half of the story is above. Here is the money half, and it comes with a trap built into it.

Against a monthly turnover of 500 000 PLN, the effect after implementation came out in nine rows:

Do not add this column up. The nine rows are measured in three different things, and a sum of revenue and profit and freed hours is a number with no unit, which means it cannot be checked and cannot be wrong.

Add the columns separately instead:

• Revenue rows: 8 000 + 15 000 + 4 000 + 5 000 + 8 000 = 40 000 PLN of additional revenue per month. Reverse check: 40 000 − 8 000 − 15 000 − 4 000 − 5 000 − 8 000 = 0.
• The other side: 5 000 + 3 000 profit, 10 000 of cost equivalent and 2 000 whose unit the table does not state = 20 000 PLN of reduced costs and leakage. Reverse check: 20 000 − 5 000 − 3 000 − 10 000 − 2 000 = 0.

Those two subtotals are the ones we work with: about 40 000 PLN of additional revenue, plus about 20 000 PLN of reduced costs. Their sum, 60 000, is a number we do not use and do not print anywhere but here, in the sentence explaining why: it would add revenue to profit, and those do not add.

Cost equivalent — work that no longer has to be done, priced at what it used to cost. It turns into money only if the freed hours are actually removed from the payroll or sold as something else; if the same people stay on the same hours doing something less urgent, the row is real as relief and zero as cash.

Two honest notes before that table is used for anything.

The ninth row has no unit. "Fewer operational errors, +2 000 PLN" is stated without saying whether that is revenue or profit. It sits on the cost side here because that is where it makes the second subtotal come out at exactly the 20 000 the table is summarised as. That is an inference, and we would rather write it down than smooth it over.

The rows are independent streams, and independence is worth checking on your own data. A returned guest whose check was also lifted by an offer is one visit; if the CRM row and the average-check row both claim it, the same money is in the table twice. Take the guests behind each row for one month and look for the same guest in two rows. Small overlap, the rows add. Large overlap, they do not, and confidence in the individual numbers repairs nothing.

Reverse check: what the 30–40 thousand band says about contribution

Not all additional revenue becomes profit, which is why the thing to count is contribution.

Contribution margin — quoted from the break-even pillar, which owns this definition: "the money left from net sales after variable costs, available to cover fixed costs and, once they are covered, to become profit. Expressed as a share of net sales it is the contribution margin ratio; expressed per guest it is the contribution margin per cover." The full treatment, including why it is not gross margin, is on the break-even page.

So the effect after variable costs is not 40 000 + 20 000. It is:

Operating effect = Additional revenue × Contribution margin ratio + Reduced costs

• Additional revenue — the revenue subtotal of the table, PLN per month;
• Contribution margin ratio — the share of that revenue left after the variable cost of actually serving it, a dimensionless fraction between 0 and 1;
• Reduced costs — the second subtotal, PLN per month, already net of the volume it took to produce.

After variable costs the effect is 30 000–40 000 PLN of additional operating effect per month. Run that band backwards through the formula and it tells you something the table alone does not:

Contribution margin ratio = (Operating effect − Reduced costs) ÷ Additional revenue

• bottom of the band: (30 000 − 20 000) ÷ 40 000 = 0.25, that is 25 %;
• top of the band: (40 000 − 20 000) ÷ 40 000 = 0.50, that is 50 %.

Forward check on both ends: 40 000 × 0.25 + 20 000 = 30 000, and 40 000 × 0.50 + 20 000 = 40 000. The band is not vague; it is a statement that the contribution ratio on the added revenue sits somewhere between a quarter and a half.

That claim can be tested against a different part of our own numbers, which is the best kind of check because it comes from somewhere else entirely. The win-back campaign ran 183 lapsed guests, 71 open conversations, 34 bookings and 27 completed visits, producing 8 460 PLN of revenue against 1 120 PLN of variable campaign and incentive cost, with additional contribution of 3 900 PLN.

Two independent parts of the same month agree, which is the only reason to believe either.

That campaign also shows why campaign cost is not the whole variable cost. Revenue minus campaign cost is 8 460 − 1 120 = 7 340 PLN, and the contribution is 3 900. The difference, 7 340 − 3 900 = 3 440 PLN, is the variable cost of actually serving 27 visits — food, packaging, card fees, the hourly labour a busy room needed. An owner who stops at "revenue minus what the campaign cost" overstates the result by that amount. How to run such a campaign without spraying a discount at the whole base is a page of its own.

Contribution ratio of a campaign = Additional contribution ÷ Campaign revenue

• Additional contribution — revenue less every variable cost caused by it, PLN;
• Campaign revenue — revenue from visits attributable to the campaign, PLN;
• worked: 3 900 ÷ 8 460 = 0.461; reverse check 8 460 × 0.461 = 3 900.

And the condition under which all of this comes out at zero, stated plainly because a page that shows only the upside is an advertisement: if the added revenue carries a contribution ratio at or near zero — deep discounting, a delivery mix whose commission eats the margin, an offer moving guests from a full-price visit to a cheaper one — the first term of the formula vanishes and the effect is whatever the cost side genuinely delivers. The table does not protect you from that. Only counting contribution per row does.

The effect next to the operating profit that was there before

One last piece of arithmetic, and it is the one that ought to slow an owner down rather than excite him.

The venue was making 40 000–50 000 PLN of operating profit a month before any of this. The operating effect is 30 000–40 000 PLN a month. Put them side by side:

Reverse checks: 50 000 × 0.60 = 30 000, and 40 000 × 1.00 = 40 000.

So the range runs from three-fifths to the whole of the profit the business used to make. That is an enormous number, and the correct first reaction to an enormous number is not enthusiasm — it is to check the two things that would make it wrong.

First, the base. The comparison only means something if your own operating profit is defined the same way — after which costs, before which. Where the money actually goes in a restaurant's P&L settles that, and it is worth settling before comparing anything to anything.

Second, the arithmetic of small bases. An effect equal to the whole of prior profit does not mean the business doubled.

Both statements describe the same money; the second merely sounds like a different business.

Nothing here is a promise. The rows in the table are what a month produced under one set of conditions. What generalises is the method — split by unit, count contribution, check independence, name the zero case — not the figures.

Where the AI is here and where it is ordinary arithmetic

This distinction matters more on this page than on most, because the words "sorted 100 000 events" invite the assumption that something clever happened to all of them.

Ordinary arithmetic, no model involved:

• every sum and share in the four-bucket table, including the remainder, which is a subtraction;
• the stock-versus-delivery comparison behind the "no action required" rule;
• the closing-time pattern: counting 7 of 11 and multiplying by 24 minutes;
• the deviation to forecast: 860 ÷ 19 600;
• both subtotals of the effect table and the contribution ratios derived from them.

You could do all of it in a notebook, and slower is the only difference. That is deliberate: an owner who cannot reproduce a number should not act on it.

Where a model earns its place:

• reading a free-text message, a call or a review and turning it into a structured event with a venue, a time and a category — this is language work and there is no arithmetic that does it;
• proposing which cause is most likely when several coincide, as with weather and a budget change on the same evening — signals from outside the business are exactly the kind that no single number in your own system explains;
• drafting the options and their consequences before a person chooses, so that what arrives is a decision to make and not a chart to interpret.

And where neither belongs: the choice itself. A rule says which events reach the owner. It does not say what he should do about them, and the moment a system starts choosing between options with different consequences for the business, the fourth bucket has stopped being his. That boundary is a setting, and a person sets it: the engine that carries the options and the recalculation of a "what if" answer are tools for arriving at a decision, not for taking one.

All of it sits on the same plumbing: events have to arrive in one place before any rule can be written over them. The queue that collects enquiries from every channel is the first of those pieces, and which system layer to add next is the question that follows. Starting from nothing, the four thresholds that tell you when automation is worth it at all is a better first read than this page.

"How are we doing?" — what that conversation is and is not

The end form of this is that the owner does not open a dashboard. He asks how things are going, and the answer is:

Good. This month we are forecasting +6.2 % against last. I see two problems and three opportunities. The first problem is already closed. The second needs a manager's decision — the task is assigned. Of the opportunities, one is immaterial. The second is worth roughly 4 000 PLN a month and I have already started a test. The third is potentially larger but needs your decision. Shall I show you?

He says "show me the third". The data opens. He asks why, and the grounds are laid out. He asks what happens if it is done the other way round, and it is recalculated. He says "fine, do it", and those two words become assigned tasks, actions, control and a later analysis of the result.

Read what that answer is actually made of, because it is the whole page in one paragraph. It is a count of problems and opportunities — the four-bucket sort. It says which items were closed without him — the second bucket. It names one that went to a manager — the third bucket. It puts a figure on one opportunity and admits another is immaterial — the effect table, row by row, rather than as a total. And it ends by asking rather than acting — the fourth bucket, unchanged.

Now read what it is not.

It is a forecast, and forecasts are wrong in a distribution.

It is not a claim that there were exactly two problems. There were two problems that rules caught. What else the month contained is in the remainder, and the remainder is not a measurement.

And it is not a reason to stop having a manager. The layers this removes are the ones that existed to move information. The work that remains — the team, the room, the conflicts, the physical operation, the situations nobody wrote a rule for — is the work a person was always needed for, and there is now more room for it. One strong manager becomes considerably more capable; one strong manager does not become unnecessary. That is also the honest limit of a filter: it makes the first instance of anything more visible by clearing the noise around it, and it still needs a person to recognise it.

What an owner gets out of this, in the end, is not fewer numbers. It is control without having to exercise all of it personally — and, if the filter is built honestly, a written list of what it is not watching on his behalf.

Frequently asked questions

Does a filter like this only work with several venues?

No, and the arithmetic is the same at one venue — the difference is what it replaces. At one venue it replaces the owner's own attention, which is free but finite. At ten it replaces layers of management, which cost salaries and add six handovers between an event and a decision. The rules themselves are identical: a condition on data you already record, plus the addressee it goes to.

How many rules do you need to start?

Fewer than most people expect, because event traffic is heavily concentrated in a handful of categories. Take one week at one venue, list the categories of thing that happened, and write a condition and an addressee for each. Most of the volume will be covered by the first few. The list will be wrong in places; that is what the second week is for.

What happens to a manager when most events stop reaching him?

His job changes rather than disappears. Information logistics — "did you do it", "did they reply", "what about the delivery", "call the guest", "remind the waiter" — is the part that a filter absorbs. The team, service quality, the atmosphere, conflicts, the physical operation and the situations nobody has a rule for are the parts that stay, and they are the parts a person was needed for in the first place.

Why can the nine effect rows not simply be added together?

Because they are measured in three different things. Five rows are revenue, two are profit, one is a cost equivalent and one has no unit stated in the source. Adding them produces a figure with no dimension, which cannot be checked against anything. Add the revenue rows to 40 000 PLN and the rest to 20 000 PLN, keep them apart, and convert the revenue side through a contribution ratio before comparing it to profit.

What does the 25–50 % contribution range actually rest on?

On reading the effect band backwards. The operating effect after variable costs is 30 000–40 000 PLN a month; the cost side is 20 000 PLN; the revenue side is 40 000 PLN. So (30 000 − 20 000) ÷ 40 000 = 25 % at the bottom and (40 000 − 20 000) ÷ 40 000 = 50 % at the top. The win-back campaign, counted separately, came out at 3 900 ÷ 8 460 = 46.1 %, which falls inside that range.

Under what conditions is the effect zero?

When the added revenue carries no contribution — heavy discounting, a channel whose commission consumes the margin, or an offer that moves a guest from a full-price visit to a cheaper one. Then the first term of the formula goes to zero and only the cost side remains, and even that is not automatic: the reduced-administrative-work row turns into money only if the freed hours actually leave the payroll or are used for something that earns.

If nothing reaches me for a month, is that good news?

It is not news at all until you know why. Silence has two causes that look identical from the outside: a calm month, and a filter that stopped firing because a threshold drifted, an integration went quiet or a rule stopped matching after something changed. Read the count of decisions next to the count of rules that fired at all, and if both fall together, check the plumbing before congratulating anyone.

Every number on this page is one we ran, and every step of arithmetic is shown so it can be repeated on your own figures rather than taken on trust. If it is useful, the rest of the section — the rules behind each of the four buckets, worked one page at a time — is here.