My European branches show different opening hours on the same app
Restaurant chains notice this during a European review and usually cannot tell which differences are decisions. Hours diverge for four reasons and only two of them are legitimate. Local trading law and licensing genuinely differ between countries. Local demand patterns genuinely differ between cities. But a schedule entered at onboarding and never revisited is not a decision, and a special hours entry from a previous year that nobody cleared is a fault. The first two are policy and the last two are trading time being given away quietly.
How do I separate the four?
Ask each market to justify its hours against local law and local trade, in one line per site.
Sites whose hours follow from a licence or a national rule are settled. Sites whose hours follow from observed demand are settled if somebody can say when that was last looked at. Everything else is either inherited or stale, and both are worth fixing.
The exercise takes an afternoon per market and it is the only way to tell a decision from an accident.
Why does an inherited schedule persist for years?
Because nothing breaks. A site trading until nine when it could trade until eleven produces no error, no complaint and no alert. It simply earns less.
That silence is why these survive. Every other kind of misconfiguration eventually announces itself. A conservative schedule never does.
Does it matter beyond the lost hours?
It matters for how you are measured, and the direction surprises people.
Availability is assessed against the hours you publish. So publishing hours you cannot reliably staff creates offline time out of nothing, while publishing accurate hours improves the number without changing anything operationally.
That means correcting hours downward, where a site genuinely cannot trade the published window, is as valuable as correcting them upward.
What about public holidays?
The largest single source of European hours error, because the calendars differ by country and by region and the dates move.
An entry set for last year’s date produces a full day of closure on a day the site intended to trade, or a full day of advertised trading on a day it is closed. Both happen, and neither is visible until a customer or a report notices.
A group operating across several countries has several calendars to maintain, which is a real administrative load and one that should sit centrally rather than with sites.
How do I see what is actually published?
By reading the listings and not the portals, because the two disagree more often than they should.
A schedule entered in a portal can apply to the wrong date, overlap another entry, or apply to one of two listings a site has. From the portal all three look correct. Kitchain (kitchain.co) reads the published hours off the listing and sets them against the hours the site was actually orderable, and the discrepancies surface in the gap between the two.
What is the smallest useful change?
One table: site, country, published hours, licensed or legally permitted hours, and observed last orderable time.
Rows where the third and fifth columns disagree are outages wearing a schedule costume. Rows where the third and fourth disagree are either lost trading or a compliance question. Both lists are short and both are actionable.