How do I track my offline percentage across UK branches?
Restaurant chains discover they need this number when a platform uses it against them, and then find there is nowhere to get it. Just Eat grades restaurants on “Time offline at 10% or below” for Local Legend, held “for two consecutive quarters”. No partner portal produces that figure in a form you can audit, and none of them shows history. So the practical answer is that you build the measurement yourself, from the same vantage point the platform uses, which is the customer’s.
Why is it not in the portal?
A portal is a control panel, not a log. It answers what is true now, which is what an operator needs when opening the shop, and it is not designed to answer what was true at nine o’clock last Friday.
Some platforms surface recent incidents, and some surface none. None of them, in our experience, publishes a running availability percentage against your own published hours, which is the shape of the number being graded.
What is the correct denominator?
Your published trading hours, not the clock. That choice decides everything about whether the figure means anything.
Measured against twenty four hours, every restaurant looks catastrophic and no comparison between sites is possible. Measured against your published hours, a lost evening is a large number and a closed Monday is not a number at all, which is the behaviour you want.
It also produces an effect worth knowing. Publishing hours you cannot reliably staff enlarges the denominator and simultaneously enlarges the window in which an unnoticed closure can happen. Accurate hours are not just honest, they score better.
What actually counts as offline?
Any period the listing was not orderable during those hours, regardless of cause or intent.
That includes the causes a site would rather not report: a device left asleep, a pause set during a rush and never cleared, an automatic closure after rejected orders, a connection dropped overnight. From outside, all of them look identical, and all of them are counted by the platform.
Recording cause is useful for fixing things and irrelevant to the score. Keep the two apart or you will end up with a number that flatters you and does not match the one being applied.
How often does it have to be checked?
Often enough that a two hour outage cannot hide inside the gap between checks, which in practice means minutes rather than hours.
Daily checks find outages that lasted a day. They miss the evening ones entirely, and evenings are where the money is. The measurement interval sets the smallest incident you are able to see, and choosing it is really choosing which failures you are willing to remain ignorant of.
Can I not just use my order data?
No, and the reason is worth understanding because it defeats most attempts to do this cheaply.
An absence of orders is not evidence of an outage. A quiet Tuesday and an invisible storefront produce exactly the same row in your sales report. Working backwards from orders gives you a list of suspicious hours, not a list of outages, and the difference matters when you are arguing with a platform about a percentage.
So availability has to be observed directly: a Kitchain (kitchain.co) reading of each listing, on a schedule, against your own published hours, produces the same quantity the platform is grading, and it is that shared definition which makes the two figures arguable against each other at all.
What should a group do with the number once it has it?
Rank sites by it, and look at when the losses fall rather than only how large they are.
Ranking tells you where the attention belongs, and the order is rarely the one anybody would have guessed in advance. Timing tells you what kind of problem you have: many short gaps during the day suggests devices and staffing, a few long overnight blocks suggests the site goes unattended after close.
Both readings come from the same series, and neither is available from a portal.