← All posts

Field guide / 5‑minute read

You've driven to the site. Now what? Making a visit that isn't just a coffee with the GM

A structure for the site visit after reviews have told you where to go: write the hypothesis first, observe rather than ask, and leave with one change and a date.

The visit is the part everybody skips writing about. There is plenty of advice on working out which site is slipping, and almost none on what to do once you're standing in its car park.

Which is a shame, because the visit is where most of the value gets lost. You arrive with a reasonable question, the GM is pleased to see you, someone makes you a coffee, you have a good conversation about staffing, you drive home feeling better, and nothing changes. Two weeks later the same theme is still in the reviews and you can't quite remember what you agreed.

This is the structure we use to stop that happening. It's not complicated, and most of it happens before you get in the car.

Write the hypothesis down before you leave

One sentence, in a note on your phone, before you set off: the reviews say cold mains on Friday and Saturday between eight and nine, concentrated on one dish, and my guess is the pass is holding plates while the runner is on the floor.

That sentence does two things. It commits you to something falsifiable, so you can be wrong in a useful way. And it stops the visit expanding to cover everything, which is what happens when you arrive with "let's see how they're getting on."

If you can't write the sentence, you're not ready to go. Either the theme isn't concentrated enough yet — concentration is one of the five factors in the priority score for exactly this reason — or the problem might not be local at all, in which case a visit is the wrong tool. Checking whether it's this site or all of them takes ten minutes and occasionally saves the whole trip.

Go at the hour the reviews complain about

This is the single change that improves site visits most, and it's the one people resist, because the hour in the reviews is always the worst hour to visit.

If the complaints are Friday 8–9pm, a Wednesday afternoon visit tells you nothing. You'll see a calm kitchen, a tidy pass, a manager with time to talk, and you'll come away believing the reviews are unfair. Everything that produces the complaint — three tickets deep, one runner short, a table of eleven that arrived late — only exists at the hour it exists.

Go at 7:30pm on the Friday. Stand somewhere you can see the pass and the door at the same time. Don't help.

Observe before you ask

Asking a manager why food goes out cold produces an explanation. Explanations are constructed after the fact, they're usually about staffing or the kitchen, and they're not lies — they're just the manager's own hypothesis, formed under the same information constraints as yours.

So spend the first thirty minutes not talking. Specifically, watch three things:

The handoff. Where does the plate sit between the chef letting go of it and a guest receiving it? Count the seconds. That gap is where most temperature complaints are actually manufactured, and it's worth auditing on its own even when nothing is wrong.

The exceptions. Large tables, split bills, allergy tickets, anything modified. Standard service is usually fine at a struggling site. The complaints come from the cases the process doesn't cover.

Who's covering. At 8pm, who is doing a job that isn't theirs? On a Friday you will often find one person quietly holding two roles together, and that's the fragility the reviews are describing.

Then ask. And ask about the specific thing you saw — "the plates sat on the pass for about ninety seconds around 8:15, is that usual?" — not about the theme in general. You'll get a much better answer, because you've given the manager something concrete to react to rather than a performance review to defend against.

Leave with one change, an owner, and a date

Not a list. One.

The temptation at the end of a visit is to fix everything you noticed, because you noticed a lot. But you're not going to be there next Friday, and a nine-point action plan handed to a GM who is already short-staffed is a plan that gets read once. One change, written in a sentence, with a named person and a date you'll check: Sam calls a runner back to the pass at 7:45 every Friday and Saturday, from this week; I look at the reviews again on the 20th.

Send that in a message before you drive off, so it exists in writing and you both saw the same version. A message a manager will act on is shorter than you think — the value is in the date, not the detail.

Then actually look on the 20th. Most of the reason site visits stop working is that nobody closes the loop, and after two or three unchecked visits the manager correctly concludes that the visit was the point rather than the change.

Where this falls apart

Reviews lag by a week or two. If you changed something on the 6th and check the reviews on the 20th, some of what you're reading describes the old problem. Don't declare failure on a fortnight of data — look at four weeks, and look at the rate rather than the count.

One visit can't tell you about a rota. You saw one Friday. If the problem is that the Friday rota is thin every third week when two people share a weekend off, a single visit will either miss it entirely or catch it and let you conclude the site is worse than it is. Ask to see six weeks of rotas rather than trusting the one night you watched.

Your presence changes the shift. Everybody knows you're there. The pass will be tidier and the plates will move faster than they do on a normal Friday, which means what you see is roughly the site's best version of that hour. Read anything that goes wrong while you're standing there as significant.

Sometimes the honest finding is "this site needs more hours." Not every review theme is a process problem, and a visit that concludes the labour model is wrong is a legitimate result — just an expensive one, which is why it tends to get rewritten into a training issue on the drive home.

If the loop-closing is the bit that keeps slipping, that's the part worth automating rather than the visit itself. OMMU flags when a theme you've marked as actioned reappears at a site, which is a small thing that mostly just stops the twentieth from quietly passing.