A guest posts a two-star review at 19:42 on a Friday. "Burger cold, forty minutes, nobody checked on us." Your kitchen is in the middle of its worst hour of the week.
There are three honest possibilities for what happens next. Nobody sees it until Monday. Somebody sees it, feels bad, and does nothing because the fix isn't theirs to make. Or it reaches the one person on the floor who can still do something about the next ten covers, while there are still ten covers left to save.
Which of the three you get is decided in about a minute, and not by how good your recovery process is on paper.
Only two things have to happen in the first minute
The mistake almost everyone makes when thinking about speed is assuming the whole recovery has to be fast. It doesn't, and it can't be. Retraining an expo handoff takes a fortnight. Fixing the holding station takes a maintenance visit. Rewriting how delivery tickets queue against walk-ins is a decision about your pass, not a decision you make between two tables.
Two things do have to happen inside that minute, because after it they stop being possible.
Classifying it. A cold burger and a guest saying their child was served the wrong meat are not the same event, and treating them the same way is how businesses end up with a cheerful automated apology sitting under an allergy complaint. That distinction has to be made before anything is sent anywhere — including before anything is sent to the guest.
Handing it to a named person who is physically present. Not the owner, who is at home. Not "the team". The person standing near the pass right now.
Everything else — the reply, the root cause, the training, the proof it stopped happening — can happen at its own pace, and does. Confusing the two is why review tooling tends to produce either a firehose nobody reads or a silence that breaks once a quarter in an expensive way.
The first decision is whether to reply at all
This is the counterintuitive part. Most systems treat an incoming complaint as a prompt to respond, and get faster at responding. The more useful first move is often to stop the response.
An everyday grumble — slow service, a loud room, chips that arrived lukewarm — should get a warm, specific public reply, and there is no good reason for an owner to be the one typing it at midnight. But a review that mentions an allergy, illness, a safety worry, or a guest who says they're taking it further is a different category of event. It needs a person, it needs the facts checked before anyone concedes anything in public, and an automated apology posted underneath it in the meantime actively makes the situation worse.
So the useful behaviour is asymmetric. Handle the ordinary ones. Hold the serious ones, and put them in front of a human immediately. OMMU is built around that split: routine reviews get answered in your voice, and the ones that could turn into something get held back and texted straight to your phone instead.
What the message has to answer
A manager reading a phone in the middle of service is asking one question: do I put this down and deal with that?
An alert that says "New 2-star review — tap to view" cannot answer it, so it gets tapped later, which means never. The message has to carry enough for the decision to be made without opening anything: what went wrong in plain words, which shift or station it points at, and what is worth doing about it today. "Cold burger, 40-minute wait, Friday dinner — check the pass, food is sitting" is a message somebody can act on while walking.
That is a higher bar than it sounds, because it means the classification has to have happened already. "Bad Food" or "Slow Service" as a category label pushes the interpretation back onto the busiest person in the building.
The four places the loop breaks
In practice, alerting systems fail for the same handful of reasons, and none of them are about speed of delivery.
It went to everyone, so it went to nobody. A group inbox or a channel with nine people in it produces a well-documented diffusion of responsibility. Someone has to own it by name.
It arrived somewhere nobody was. A notification inside a dashboard is only an alert if somebody is logged into the dashboard. During service, nobody is.
It was the fortieth one this week. Alert on everything and you have taught your team that these messages are furniture. The value of an urgent message is almost entirely a function of how rarely it arrives, which makes restraint a feature rather than a limitation.
Nothing remembered it happened. This is the expensive one. If each complaint is handled and then forgotten, the third occurrence of the same problem looks exactly like the first, and gets the same apology instead of the fix it has been asking for since March.
The other half is slower, and it's the half that pays
The minute-long part saves a table. The part that actually changes your P&L happens over weeks, and it needs the opposite treatment: not urgency, but memory.
Once complaints are classified consistently, they aggregate. Nine "cold food" mentions in a month, seven of them between 18:00 and 21:00 on a Thursday, is not a service failure — it is a capacity failure with a rota fix, and no individual recovery would ever have revealed it. That is the job of a weekly summary rather than a text: one short read that says what changed, which site or shift needs attention first, and what to do before the weekend.
The most underrated line in that summary is the one about a complaint that stopped appearing. It is the only evidence you will get that a fix took hold, and it arrives free, written by guests, without anyone running a report.
What to take from this
If you want to pressure-test your own setup, the questions are short. When a serious complaint lands during Friday service, who specifically gets told, on what device, and how long does it take? Would they be able to act without opening anything? Is anything counting how often the same problem recurs?
If the honest answers are "the shared inbox", "whenever someone checks it" and "no", the gap isn't your recovery script. It's the sixty seconds before the script gets used.
That is the whole of what OMMU is for: it reads reviews as they land, answers the ordinary ones in your voice, texts you when something genuinely needs you, and sends one plain-English email a week on what to fix next. If you want to see the real thing rather than a description of it, the sample report is an actual morning briefing sent to a multi-location owner — same words, same numbers — or book a fifteen-minute check-up and we'll go through your last month of reviews together.