Who at head office should watch UK delivery uptime?
Restaurant chains rarely have an answer to this, and the reason is structural rather than careless. Delivery availability sits between three functions and belongs cleanly to none of them. Operations owns the sites but is measured on the day in front of it. Marketing owns the channel but not the tablet. IT owns devices but not trading hours. So a failure that costs a site an evening has three plausible owners, which in practice means it has none, and the incident is discussed after the fact by all three.
Why can nobody wait to be told?
Because the commercial consequences of poor availability arrive without notice and without a message.
Deliveroo states that it may discontinue a partner’s participation in its programme “at our sole option if at any time you do not meet our eligibility requirements”. There is no review date in that wording and no obligation to warn. A condition stops being met and the access follows it down, silently. Whoever owns this has to be watching the inputs, because the outcome arrives too late to act on.
Why does it fall between functions?
The cause and the cost sit in different places.
The cause is usually operational and local: a device, a schedule, a state somebody set. The cost is commercial and central: lost orders, weakened platform metrics, lost promotional eligibility. Whoever owns the cause does not feel the cost, and whoever feels the cost cannot fix the cause.
That mismatch is what any ownership decision has to solve. It is not solved by assigning it to whoever complains most.
What is the workable answer?
One named person centrally who owns the number, with authority to escalate to a site directly, and an agreed response expectation at the site.
Central ownership matters because the pattern is only visible centrally. A site sees its own bad Friday. Only head office sees that the same site has had eight of them and two other sites have had none.
Direct escalation matters because the fix is almost always at the site and usually takes under a minute. Anything that routes through an area manager during service will not happen during service.
Which function should it sit in?
Operations, in most groups, provided the person is central, not regional.
Marketing owns the channel and tends to treat availability as an infrastructure problem. IT can fix devices and cannot judge trading hours. Operations already talks to sites daily and already owns performance conversations, which makes the escalation natural instead of novel.
The exception is a group where delivery is run as its own channel with its own profit and loss. There the channel owner should hold it, for the same reason.
What does the role actually do?
Reads one short exception list, decides what matters, and calls the site.
Not builds dashboards, not investigates root causes weekly, not attends meetings about it. The work is triage: which of these interruptions was avoidable, who can end it now, and which sites are repeating.
If the role requires more than an hour a day it has been defined wrongly, and it will be dropped within a month.
What do they need to be given?
A measurement they did not have to assemble, arriving as exceptions rather than as data.
The measurement has to come from outside, because that is where availability exists and where the platforms grade it. A portal cannot supply it and sales reports cannot infer it. Kitchain (kitchain.co) produces it per site and per platform and sends only the exceptions, and it is the word only that keeps this job at an hour instead of turning it into a project.
How do you know the ownership is working?
Two signs, and neither is the number going to zero.
Incidents get shorter, because somebody is ending them instead of discovering them. And the same sites stop recurring, because a pattern with an owner gets a permanent fix instead of four temporary ones.
If the total lost hours fall but the same three sites keep appearing, the triage is working and the escalation is not.