An area manager gets sent to a site with a portion complaint problem. They arrive, look at the plates, find them within spec, coach the kitchen on presentation, and leave. Three weeks later the site next door reports the same thing.
The complaint was never local. A spec change in July reduced a garnish across the group, and six sites are now individually discovering it, badly, one at a time.
This is the most expensive error in multi-site review analysis, and it is easy to avoid with one check nobody does.
The check
Before acting on any theme at any site, ask: what is this theme doing at the other sites?
Three possible answers.
Only here. A genuine local fault. Go and look.
Everywhere, at a similar rate. A system fault. The site is not the unit of analysis and sending anyone there is wasted. Find what changed centrally.
Everywhere, but much worse here. The most common and most interesting case. A system cause with a local amplifier — the group spec is tight everywhere, and this site's layout, volume or staffing makes it bite harder. Both fixes are needed and the central one comes first.
Ten minutes. It requires theme counts per site, which is the same table the audit procedure produces.
What system faults usually turn out to be
They cluster into a small number of causes, and all of them share a signature: a date.
- A spec or recipe change. Portion, garnish, ingredient substitution. Shows up as portion or quality complaints 2–6 weeks after the change, because guests need a comparison visit.
- A supplier change. Consistency and quality complaints, often described as the food "tasting different".
- A price or menu change. Value complaints, and they arrive fast — within a fortnight.
- A policy change. Service charge, booking terms, table time limits. Almost always produces money and expectation complaints, and almost always the ones about surprise rather than amount, as in the surprise audit.
- A rota or labour model change. Attention and speed complaints, group-wide, usually starting on the busiest daypart.
- A booking or ordering system change. Wait and accuracy complaints, and frequently invisible to head office because each site assumes it is their own configuration.
The pattern to look for is a theme rising at several sites within the same few weeks. Then find what changed in the month before, which is a question for your own change log rather than for the reviews.
Why local explanations win by default
Worth understanding, because the bias is strong and predictable.
A site has a manager who can be spoken to. A system has no owner in the room. When a theme appears, the available action is a conversation with a GM, and the available action gets taken.
Local explanations are also more flattering to the centre. "Old Mill has a coaching problem" is a comfortable conclusion; "the July spec change cost us across the estate" is not, and it implicates the people doing the analysis.
And the sites themselves rarely push back, because a GM told their portion complaints are a local execution issue has no visibility of the other five sites and cannot argue.
The tell that you have got it wrong
The same fix keeps getting made. If your last four site visits produced similar coaching on similar themes, you are treating a system fault as a series of local ones. Four sites do not independently develop the same problem in a quarter.
The fix does not hold. A local fix on a system cause regresses within about six weeks, because the underlying condition is unchanged. Repeated regression at one site is usually read as a management problem at that site, which is how the wrong GM gets performance-managed for a head-office decision.
The one case for going anyway
If the rate is dramatically higher at one site even after you have identified a group cause — the third answer above — the local amplifier is real and worth finding. A group-wide spec change that produces 0.4 complaints per hundred covers at five sites and 1.2 at the sixth is telling you something specific about that sixth site.
Just do the central fix first, or the visit will be a conversation about a constraint the site does not control. What to actually do when you get there is a separate question, and it goes considerably better when the visit is not about something head office caused.
Making the check routine
Keep a change log. Date, what changed, which sites. Menu changes, spec changes, supplier switches, policy changes, system changes. Most groups have this information scattered across four inboxes, which is why the correlation never gets made.
Then, whenever a theme rises at more than one site, read the log for the preceding six weeks before anybody gets in a car.
The theme counts have to be current and consistently tagged across every site for any of this to work, which is the recurring practical obstacle — six sets of reviews tagged by six people are not comparable. That consistency is what OMMU holds: the same tagging across every location, so "portion complaints are up at four of six sites since the twelfth" is a sentence somebody can actually check against the log.