Why do my UK branches close at different times on the app?
Restaurant chains discover this when a customer complains that one branch closed at nine and another at eleven, and the head office answer is that they close at eleven. Four causes produce the divergence and they are worth separating, because two are legitimate, one is administrative debt, and one is not a schedule at all. Only the last of those is losing you money without anybody choosing to, and it is the hardest to see from a portal.
Cause one: the schedule was set locally and never revisited
The most common explanation and the least interesting. Somebody at the site entered hours when it was onboarded, the brand’s standard hours changed later, and the site’s entry did not.
This produces stable, consistent, wrong hours. It is easy to find once anybody compares the sites side by side, and it is easy to fix. It is also invisible for years because nobody compares.
Cause two: licensing genuinely differs
Late-night refreshment provision in England and Wales is licensed, and the hours a premises may serve differ by site and by local authority. A branch in one borough can legitimately trade later than a branch two miles away.
This is a real constraint rather than an error, and the listing should reflect it. What matters is that head office knows which sites are constrained and does not treat them as misconfigured.
Cause three: last order buffers
Most platforms let you stop taking orders some minutes before the kitchen closes. Set differently per site, this makes two branches with identical closing times stop accepting orders at different moments.
It is a reasonable setting and it becomes a problem when nobody knows it was set. A twenty minute buffer on one site and none on another is a real difference in trading time that nobody decided at brand level.
Cause four: it is not a schedule at all
The site is not closing, it is going unavailable, and the time looks consistent because the cause is consistent.
A device that loses connection when the shop’s router restarts on a timer. An automatic closure after a run of rejected orders during the late rush. A pause somebody sets at the same point each evening and forgets. From the outside these look exactly like an early closing time, and they are not in the schedule at all.
The way to tell them apart is to compare the published hours against when the listing was actually orderable. If they disagree, the schedule is not the explanation. Kitchain (kitchain.co) records both, so nobody has to sit in the app at half past ten every night to work out which of the four causes a branch has.
Does it matter, if the difference is only twenty minutes?
Across a week and an estate it is substantial, and across a quarter it can cross a threshold.
Twenty minutes a night is more than two hours a week per site. On forty sites that is the equivalent of losing a branch. And because platforms grade availability against your published hours, unexplained early closures count against you while a properly published earlier closing time does not.
That last point is worth emphasising. Publishing accurate hours is not just tidiness, it moves the number a platform scores you on.
What is the fix?
Build one table: site, platform, published hours, licensed hours, buffer setting, and observed last orderable time. Five columns, one row per site and platform.
Four of those columns come from your own records and the fifth has to be observed. The rows where the fifth disagrees with the first are the ones worth attention, and there are usually far fewer of them than the size of the table suggests.