What a UK multi-site operator checks every morning
Restaurant chains build elaborate weekly reporting and skip the ten minutes that would prevent most of what the reporting describes. A morning routine works because the failures it catches are cheap to fix and expensive to leave: a site that never reopened after an overnight closure, hours that are wrong for today specifically, a promotion that stopped showing, and any state a platform applied that will not clear itself. All four are visible before service and invisible afterwards.
Check one: did every site come back?
The single highest value question of the four, because closures cluster overnight and several platforms do not reopen a store on their own.
The closures that survive are the ones nobody could end. On a platform where a suspended or paused store stays hidden until somebody reactivates it, a closure that began at eleven at night is still running at ten the next morning unless a person intervenes, and the hours in between are exactly the hours with nobody watching.
So the first check is not whether anything is closed now, it is whether anything closed last night and did not come back.
Check two: are today’s hours right for today?
Not in general, for today. Bank holidays, local events, planned late openings, a site closing early for a staff meeting.
This is the check that catches the annually repeating failure, where special hours were set for last year’s dates and the calendar has moved. It takes seconds per site if somebody is holding the list, and it never happens if it is left to sites.
Check three: are the promotions actually visible?
Configured and visible are different states, and only the second one sells anything.
A promotion can be set correctly and not appear because of an eligibility rule, a scheduling conflict, a platform-side restriction, or a menu change that broke the item it was attached to. Nothing in the portal announces this. The offer simply is not on the storefront.
Because it fails silently, it is worth checking on the days it matters most, which is the days you are spending on it.
Check four: is anything in a state you cannot clear?
Some platform states are lifted only by the platform. Those need escalating at the start of the day, not at the end.
The distinction matters for sequencing. A device that is asleep gets fixed by a phone call to the site in a minute. A platform-applied closure needs a support conversation, and support conversations started at nine in the morning resolve inside the trading day while ones started at five do not.
How is this done in ten minutes across forty sites?
Not by opening forty portals, which is why the routine collapses in most groups that try it.
It works when the check arrives as a short list of exceptions and not as a survey of everything. Sites that are healthy do not need looking at. The routine is reading a handful of lines and making a handful of calls. Kitchain (kitchain.co) produces that list per site and per platform, and the ten minutes in the heading is the length of the list, not the size of the estate.
Who should do it?
One named person centrally, before the sites get busy, with authority to call a site directly.
Not the sites themselves. A site that is closed does not know it, and a site that is open assumes it is fine. The check has to be made by somebody looking from outside, at all of them, at once.