From Complaint to Cause: One Is Never the Whole Story

19:20: what the message contains, and what it does not

The signal arrives in the middle of service. Everything needed to check it already exists inside the restaurant: the booking number, the time the order was fired, the current status of the dish in the kitchen. In most venues those three facts live in three different places — the reservation book, the till, and the head chef's memory — so the manager reconstructs them by walking to the pass and asking. The walk costs three to five minutes, and those minutes are spent while the guest is still sitting there waiting.

What the message does not contain is almost everything you need. It does not say which of the two mains is late, whether the starters arrived, whether anyone at the table was told anything, or when the guest started counting. The complaint is evidence of a feeling, not evidence of a time. Treating the sentence as a measurement is the first and most common mistake, and it works in both directions: it makes the venue defensive when the ticket says twenty-two minutes, and complacent when the ticket says forty-one.

So the first operation is a conversion: turn a sentence into a case with a booking number, a table, a course and a clock. A system that watches the messaging channels does this without anyone walking anywhere — the guest wrote from a channel that already carries the booking, and the messenger channels are the same queue the venue answers everything else in. How that single queue is built, and why five channels answered separately produce three different answers to the same guest, is the subject of one queue instead of five inboxes.

And 35 minutes is the guest's count. It starts when the guest believes it started — usually when the starter plates were cleared. The kitchen's count starts when the ticket was fired. These are almost never the same clock, and the gap between them is not dishonesty on either side.

Confirming the delay: which clock starts, and where the minutes go

A dish has at least four timestamps, and each of them belongs to a different person:

The kitchen answers for the third minus the second. The guest experiences the fourth minus the first. Between them sit two queues nobody owns: the time an order waited on the till before it was fired, and the time a finished plate stood under the lamp before somebody carried it. Both gaps are invisible in the kitchen's own record, which is exactly why a venue can have a chef who is honestly right about the cook time and a guest who is honestly right about the wait.

The confirmation, then, is a subtraction and a comparison, not a judgement:

Wait for the course = time delivered to the table − time the order was fired. Both sides are minutes, so the result is minutes. In our own case the guest reports 35 minutes at 19:20, the booking gives the order time, and the kitchen status gives the stage the dish is at. The breach is 35 − T > 0, where T is the venue's own target for that course. Checked backwards: if T were 35 minutes or more, the same data would produce "within target" and no priority would be created at all. Our case produces a confirmed breach, so T is below 35 minutes — which is what the data says, and the only thing it says.

What the subtraction does not do is say whose minutes they were. A dish that cooked quickly and then stood at the pass is late and cold, and the kitchen's own screen shows it as on time; a venue that measures only cook time will look for the cause in the kitchen forever. How the same minutes read from the other side — as seats occupied and not turned — is table turnover, and the money they cost per seat is RevPASH.

A service-time target is a promise, not an average

You cannot confirm a breach without a target, and most venues do not have one. They have a feeling that mains take about twenty minutes, which is not the same object: a feeling cannot be breached, so every complaint becomes an argument about whether it was long.

A usable target has three properties. It is per course group, not per restaurant — a steak and a soup do not share a promise. It is per daypart, because the same kitchen at 19:20 on a full Friday is not the kitchen at 14:00. And it is stated as a share, not an average: nine mains out of ten within X minutes, rather than X minutes on average. The average is the wrong statistic here for a plain reason — complaints come from the tail, and the tail is what an average hides. A kitchen can hold a perfect average and still produce one forty-minute plate an evening, and it is that plate, not the average, that writes the message.

This page prints no number for X, and the omission is deliberate. Our source records that the target was breached; it does not record what the target was. Filling that blank with a plausible twenty would be inventing a fact about someone's kitchen, and a made-up number is more dangerous than a missing one because it reads as measured.

There is a cheap test of whether a target is real rather than declared. Ask three people separately: what number is the kitchen given, what number does the floor quote when a guest asks how long, and what number does the weekly report measure against. If the three answers differ, the venue has three targets, which is the same as having none.

The first reply belongs to the guest, not to the investigation

Two things now happen in parallel, and confusing them is what turns a fixable evening into a lost one.

The guest gets an answer, and it is short: the delay is being checked, someone is on it. Correct, immediate, and containing no cause, no blame and no estimate that has not been confirmed yet. The temptation is to promise five more minutes; a promise made from the floor without the kitchen status is simply a second complaint scheduled for 19:26.

The floor manager gets a priority — a task with a name on it, not an announcement into a group chat. A message that everyone can see is a message nobody owns, and the whole reason the case is escalated is that somebody must physically walk to that table. In our own working setup this is exactly what happens next to the guest's reply: the case is raised for the floor manager while the answer to the guest has already gone out. Where such assignments live and how they are closed is the tasks side of the system, and the general shape of an answer that goes out immediately without anybody typing it is described in follow-up automation.

The division of labour is the whole design, and it states plainly: answering is safe to automate, because it commits nothing. Remedying is not, because it spends money and makes promises. The same three modes run through what a restaurant system can actually take over — what it does alone, what it prepares for a person, and what only the owner decides.

Compensation is the venue's decision, and a person confirms it

This is the point where a helpful system and an unsupervised one part ways, so the order of operations matters more than the wording.

In our own case the sequence is: the delay is confirmed from data → the venue's policy is checked → if the venue has allowed compensations, the system proposes one — delay confirmed, a dessert or a drink on the house under the restaurant's policy, apply? → the manager confirms → only then is anything given away.

Three conditions, all of them before the guest hears any offer. First, a written policy exists — what may be offered, up to what value, by whom, in which situations. Without it there is nothing to check, and "the system decided" is not a policy. Second, the delay is confirmed against the target rather than against the complaint. Third, a named person confirms this particular instance. Nothing on this page should be read as a system handing out desserts: it prepares a decision and waits.

Why insist on the human confirmation when the rule could simply be coded? Because a comp is a payment out of margin made in front of a guest, and it is regularly the wrong remedy. The table that has been waiting 35 minutes usually wants the food, an explanation and someone's attention — a free dessert offered instead of those three reads as a purchase of silence. A manager standing in the room knows which of the two is happening. A rule does not.

And a comp is a cost with a category, not an absence of revenue. Written off as "less revenue" it silently distorts the average check and the food cost at once; recorded as what it is, it becomes a number the owner can look at monthly and compare against the delays that caused it. Which numbers a report should carry at all — and which ones nobody has ever acted on — is the reporting question.

What the follow-up is for — and what it must never become

After the guest has left, the case is not closed, because nothing has been learned yet. A short follow-up does two things that the evening itself could not.

It completes the record: what actually happened at the table. Whether the starters came on time, whether anybody said anything, whether they were in a hurry. This is the only source for the half of the story the tickets do not contain, and it is worth more than the complaint text.

It measures the recovery: did that guest come back. This is the honest outcome of the whole operation, and it takes a month to read, not an evening. The arithmetic of counting returning guests is repeat rate, and what a saved guest is actually worth over the whole relationship is guest lifetime value. Our own numbers give a sense of the scale on the other side of the same coin: a return campaign to 183 lapsed guests produced 27 visits and 8 460 PLN, which is 8 460 ÷ 27 = 313.33 PLN of revenue per recovered visit — reverse check, 27 × 313.33 = 8 459.9, matching 8 460. Winning a guest back later is a project with a cost; keeping the one already sitting in the room is one conversation.

What the follow-up must never become is a request for a public rating. Asking a guest you have just failed to go and rate you is a different act from asking how the evening ended, and it reads as one. Reviews have their own arithmetic — how many reviews it takes to move an average — and their own etiquette: who answers a review, when, and what is never automated. It must not become a coupon either: a discount sent after every complaint teaches a small number of guests exactly what to complain about. The follow-up channel is for finding out and for saying something true, not for paying.

A breached target and a ruined evening are two different facts

The measurement answers one question: did the kitchen keep its promise. Whether the guest was right — whether the evening was actually spoiled — is a different question with a different source, and the two agree less often than anybody expects. There are four cases, and only one of them is the one everybody discusses:

The bottom-left cell is where the money quietly goes. Most breaches produce no complaint at all: people who wait too long usually say nothing and simply do not come back, which is why a venue that counts complaints is counting the small, loud, biased sample of its own failures. Patterns must be looked for in the measurements, not in the complaint stream — that single sentence is most of the difference between a venue that fixes causes and one that answers letters.

The top-right cell is the trap in the other direction. The dish arrived inside the target, and the evening was still ruined: nobody warned them that the dish takes long, the starters had been cleared twenty minutes earlier, they had a train to catch, the table next to them was served first. Here the data is right and irrelevant. Answering such a guest with "our records show we were within target" wins the argument and loses the guest — and it is precisely what a venue does when it treats the SLA as the answer to both questions instead of one.

So keep two columns and never let one prove the other. The target tells you whether the kitchen has a problem. Only the guest tells you whether the evening had one. The follow-up above exists because the second column has no other source.

One complaint is an event; three alike are a cause

A restaurant that has learned to answer complaints well will apologise forever. The answering is necessary and it changes nothing about tomorrow: the same dish will be late again next Friday, to a different guest, who will get the same excellent apology.

The scale changes when the question changes. "What do we do about this guest?" is answered tonight and costs minutes, plus possibly a dessert. "What do we change so that this stops?" is answered the next morning and costs a recipe, a station or a rota. The first is service. The second is management, and the second is only possible when somebody notices that the case was not single.

In our own case that is exactly what happens after the guest has gone: three similar delays turn out to be connected to one group of dishes, and on the following day a separate kitchen analysis appears. Nothing about that sentence is dramatic, but it is the entire difference between a complaint desk and a system: the third case was not answered — it was counted.

This is also why the day closes with one line rather than a report. Our own day-close carries the numbers and then a single sentence: there is one situation worth looking at tomorrow, an increase in cooking time for one category. Everything inside the norm is not printed at all. At the other end of the same principle sit our numbers from a chain: out of 100 000 events, 99 650 needed no attention, 327 were settled by the system or the staff, 20 needed management, 3 needed the owner.

What makes three cases "the same": choose the key before you count

"Three similar delays" is only meaningful if similarity was defined before the counting started. This is the part everybody skips, and skipping it is what produces confident nonsense.

A key is a small set of fields that three cases must share: the dish group (not the individual dish), the station the group passes through, the daypart, the channel — dine-in, takeaway, delivery — and, if you can, the load on the floor at that moment. Write the key and the window down first, then count. Choose the key after looking at the cases and you will always find one: with enough fields, any three events in a restaurant share something. Three Fridays. Three tables by the window. Three guests who ordered wine.

The level of the key is the craft. A single dish is too narrow — you will wait months for a third case and fix a symptom when it comes. "Mains" is too broad, because it names no mechanism. The useful level is the one where a physical cause could live: one grill, one prep step done in the morning, one supplier's ingredient, one station during peak. Our own case is stated at exactly that level — one group of dishes, not one dish and not the whole menu.

And every key needs its denominator: how many orders in that same key went out in the same window. Three late plates from the group the venue sells most of is a very different finding from three out of a group that leaves the kitchen twice a night. Without the denominator the analysis will always accuse the bestseller, because the bestseller produces the most of everything — including the most delays while being no slower than anything else.

How many is enough to stop being coincidence

Repeatability is not a count. It is a count compared with the count you would have got anyway:

Expected cases = orders in the key × the venue's usual breach rate. Cases equal orders multiplied by cases-per-order, so the dimensions hold. If your own numbers put the expected figure near one and you observe three, you have something. If the expected figure is already three, you have found your base rate, not a cause.

Our own numbers from a different corner of the same restaurant show how the check reads. A particular combination of staff closed late in 7 of the last 11 shifts, running 24 minutes over the norm. For 7 to be the expected number, the venue's usual late-closing rate would have to be 7 ÷ 11 = 0.636 — reverse check, 11 × 0.636 = 7.0. So the question that decides whether this is a pattern is simply: does this venue normally close late on two shifts out of three? If it does not, the combination is the finding.

Which gives the working rule: three is the threshold for a hypothesis, not for a conclusion. One case is an event. Two cases are a story, and stories are agreed with too easily. Three cases sharing one key give you something testable — and the test, not the count, is what settles it. That is how our own closing case was actually resolved: a new order of closing tasks was tried on the next five shifts and the average closing time came down by 18 minutes, and only then was it recorded as a decision that worked.

A warning about those two numbers, because they are the kind that get merged by accident. 24 minutes is the excess on the shifts with that staff combination; 18 minutes is the reduction in the average closing time across the test. They are measured on different sets, so 24 − 18 = 6 is not a statement about anything. The units match, which is what makes the mistake easy; the denominators do not.

For a small venue there is a blunter second rule, economic rather than statistical: if two cases already point at the same nameable step and the fix is cheap and reversible, do not wait for the third.

Two ways to be wrong, and they cost differently

Seeing a pattern that is not there. The classic route is the base rate: the busiest group produces the most delays and gets blamed for being busy. Then there is the key chosen after the fact, the three cases that share one already-fixed cause — a supplier who was late that one day — the same party counted three times because three people at the table complained, and the loud guest whose three visits produce three messages. The cost is not only the wasted change. A recipe altered or a rota rewritten for nothing teaches the team that the analysis is noise, and the next finding, the real one, is met with a shrug.

Missing a pattern that is there. The key was too narrow, so three cases were filed as three dishes. The window was too short, or so long that the cases drowned. The delays were split across dine-in and delivery and stored in two systems, so nobody ever saw the third. The shifts were different, so no single person witnessed more than one. And the largest cause of all, from the section above: the venue counted complaints instead of measurements, and the silent majority of breaches was never in the data to begin with. The cost is the venue apologising forever, guests leaving without saying why, and a fix that gets more expensive the later it is made.

The two errors are not symmetrical, and the asymmetry gives a decision rule you can write on the wall. At the hypothesis stage, prefer the false alarm — testing a wrong idea costs a week of counting. At the change stage, prefer to miss — rebuilding a station, retraining a team or reprinting a menu is expensive to do and more expensive to undo. In other words: be generous about what you investigate, and strict about what you change. Confusing the two thresholds is how venues end up both jumpy and slow.

The next morning: what a kitchen review must produce to count

A review that ends in "we'll keep an eye on it" has changed nothing and consumed an hour. The minimum output is six lines, and they fit on one page:

• the key and the window — which group, which station, which daypart, which days;
• the count and the denominator — three delays out of how many orders in that key;
• the named step where the minutes appear, stated as a mechanism and not as a person;
• one change, not four, because four changes tested together tell you nothing about which worked;
• the measure and the window of the test — the same key, counted the same way, for a stated number of shifts;
• the name of the person who owns it.

Then the part most venues never build: the memory. What problem was found, which decision was chosen, why it was chosen over the alternatives, who executed it, what was expected, what came out in fact, and whether the approach should be used again. A business that keeps this stops re-solving the same problem every couple of years — and the forgetting is invisible, because nobody misses a lesson they cannot remember having learned.

This is also the level at which the owner should meet the story at all. Not the complaint, not the apology, not the dessert — one line the next morning saying that one category is cooking slower, and a decision to take about it. What the assembled version looks like is an AI restaurant management system; the analytics side is simply the part that keeps the count while everyone else is working service.

What this costs in a notebook, and where the guest's data lives

None of the above needs software. The notebook version is a sheet at the pass with five columns — date, time fired, time delivered, dish group, and whether the guest said anything — filled in for the courses that felt slow. Twenty lines a week is enough to see a group standing out. On Sunday, count by group, divide by the orders that group sent out, and compare with the venue's usual share. That is the whole method, and any owner can run it with a pen.

It fails for one reason, and it is not arithmetic. Nobody fills in a sheet during Friday service. The rows that matter most — the busiest twenty minutes of the week — are exactly the rows that never get written, so the paper record is biased towards quiet evenings, which is the opposite of what you need.

So a system earns its place in three narrow spots: it stamps the times without anyone remembering to, it holds the key and the denominator so that a count means something, and it raises the case when a key produces more than that key usually produces. It does not decide the compensation and it does not decide the change; those stay with people by design. The guest's side of the record — visits, preferences, what happened last time — is the guest database, and the complaint history attached to it is what makes the reviews and feedback part more than a wall of stars.

One boundary to state plainly, because it applies from the first message onward. A complaint record ties a named person to a visit, a table and a grievance. Keep it for the purpose it was collected for — recovering that visit and finding the cause — answer on the channel the guest wrote from, and stop messaging when they ask. This page names no article of law on purpose: a wrong article number reads more confidently than a right one. Your privacy notice is the place for that statement, and it should say what a complaint record contains and how long you keep it.

Frequently asked questions

How long is too long for a main course?

There is no universal number, and this page prints none. The usable answer is the one your own venue can keep: a target per course group and daypart, stated as a share rather than an average — nine out of ten mains within X minutes. What makes a target real is that the kitchen is given the same number the floor quotes to guests and the report measures against. Our own case records a confirmed breach at 35 minutes without recording the target, so the only thing that follows is that the target was under 35 minutes.

What should the first reply to a waiting guest say?

That the delay is being checked and someone is on it. Nothing about the cause, nothing about blame, and no estimate that has not been confirmed by the kitchen. An invented "five more minutes" produces a second complaint six minutes later. The reply can go out immediately and automatically; the remedy that follows it cannot, because it commits the venue to something.

Should we give a free dessert every time?

No, and the decision is not the system's to make. In our own working sequence a compensation is proposed only if the venue has allowed compensations in a written policy, only after the delay has been confirmed from data, and only as a question to a manager who confirms it. A table that has waited 35 minutes usually wants the food, an explanation and attention; a dessert offered instead of those three reads as a purchase of silence. And a comp is a cost with a category, not a smaller sale.

How many similar complaints make a pattern?

Three sharing one key make a hypothesis, not a conclusion. The number that matters is not the count but the comparison: expected cases equal the orders in that key multiplied by your usual breach rate. If the expected figure is near one and you saw three, investigate. If the expected figure is already three, you have measured your base rate. In our own closing-time case, 7 late shifts out of 11 would only be normal if the venue closed late on 7 ÷ 11 = 63.6% of shifts.

What counts as "the same kind of delay"?

Cases that share a key you wrote down before counting: dish group, station, daypart, channel, and if possible the load on the floor. The level should be one where a physical cause could live — one grill, one prep step, one supplier's ingredient — because a key that names no mechanism cannot be tested. And every key needs its denominator: three late plates out of the group you sell most of is a different finding from three out of a group that leaves the kitchen twice a night.

Does answering the complaint fix anything?

It saves the evening and sometimes the guest, and it changes nothing about next Friday. Answering is service; finding the repeated key and changing one step is management. A venue that only does the first will apologise forever, in perfectly good English, to a new guest each time.

What happens to the guest's data after the case is closed?

It stays tied to the visit for the purpose it was collected for — recovering that visit and finding the cause — and it should be answerable on the channel the guest used, with an easy way out of any further messaging. This page names no article of law deliberately: a wrong reference reads more convincingly than a correct one, and the right place for the statement is your own privacy notice, which should say what a complaint record holds and for how long.

One complaint answered well is a good evening. Three complaints counted properly are a kitchen that stops producing them. If you want to see how the rest of the restaurant's numbers fit around this one, the whole series lives in the restaurant section.