Every venue with a review problem has a triage framework somewhere. Far fewer can answer a simpler question: when a two-star review landed last Thursday evening, whose job was it?
Usually the honest answer is "the owner, eventually". Which works at one site and stops working at three, and produces the specific failure where a review sits for five days not because anyone decided to leave it but because everyone assumed someone else had it.
Four roles, and what each should never do
The duty manager runs the triage on the night, escalates anything alleging harm, and gathers facts. They do not write public replies to serious complaints — not because they cannot write, but because a reply composed at 10pm by someone who was on the floor during the incident is the reply most likely to be defensive.
One named replier per site clears the everyday queue: positives, four-star caveats, minor complaints, anything with a checkable fact already checked. One person, not a rota. The reason is voice — a profile where replies are written by four different people reads as institutional rather than personal, and readers notice the inconsistency even if they could not describe it.
The GM owns the pattern rather than the individual review. Their job is the weekly count, not the replies, and confusing those two is why GMs end up doing review admin instead of operations.
The owner replies personally to a short list, below.
The most common structural error is making the GM the replier. It is a natural assignment and it guarantees the job gets dropped every time service is difficult, which is every time a review is likely to need answering.
The two handoffs that actually break
Night to morning. A review lands at 9.40pm. The duty manager sees it, decides it needs the owner, and — this is the failure — puts it in a WhatsApp group.
Group chats are where escalations go to die. There is no acknowledgement, no owner, and the message is buried by breakfast. The fix is unglamorous: a named individual, a direct message rather than a group, and a required reply of any kind. "Seen" is enough. The absence of an acknowledgement step is the single most common reason a serious review sits for two days.
Site to area. A complaint that is really a systemic issue — a supplier, a recipe, a policy — gets replied to locally and never travels. The site handled it correctly and the pattern remains invisible, which is how the same complaint gets solved separately and badly at four locations. Distinguishing local faults from system faults is its own piece, but the process requirement is just that somebody at area level sees complaint themes rather than complaint replies.
The reviews the owner should answer personally
Short, and worth writing down so it is not decided case by case:
- Anything alleging illness, injury or an allergic reaction — after the incident process, not instead of it
- Anything naming a staff member in a serious accusation
- Anything from a guest who has already complained once and is back
- Anything mentioning legal action, press, or environmental health
- Anything where the venue was genuinely, unambiguously in the wrong
Everything else is delegable, and treating it otherwise is why owners end up with an eleven-deep queue. The value of the owner's reply is scarcity — a personal response means something on the four reviews a quarter that warrant one, and means nothing if it is the default.
Making delegation survive contact with the profile
The objection is always voice: nobody else sounds like me. Fair, and solvable in about an hour.
Take twelve replies you wrote and liked. Mark what they have in common — sentence length, whether you apologise, whether you use the guest's name, whether you sign off with a name and email, whether you ever explain. That document is what makes the named replier viable, and it is more useful than any template library because it encodes the judgements rather than the wording.
Then read the first month of their replies before they post. Not after.
The bit that no structure fixes
Even with named owners and working handoffs, the queue depends on people remembering on the worst night of the month. That is not a process problem. It is a coverage problem, and it is why we built OMMU around it: the everyday queue is answered in your voice without a person in the loop, and the short list above arrives as a text to a named phone rather than a message in a group nobody acknowledges.