Why the same outage costs different amounts at different branches
Restaurant chains that finally start counting lost hours run straight into a second problem: two branches with identical downtime have not lost identical amounts, and ranking them by hours produces the wrong priority list. Five things move the number, and the length of the outage is only one of them. The other four are yours rather than ours, because we measure none of them: the hour the outage landed in, that platform’s share at that branch, whether a sibling branch caught the order, and what the hour was already committed to.
What makes an hour of downtime a different quantity at two branches?
The position of the hour in the week, before anything else. Delivery demand at most restaurants concentrates into a small number of hours, and how sharp that concentration is differs from branch to branch. A residential branch may take most of its week across four evening windows, while a business district branch spreads the same volume across weekday lunches. Three hours removed from a Friday evening at the first is a different fraction of the week from three hours removed from a Tuesday lunch at the second. That shape lives in your own order data rather than in ours, and it is the first thing to pull, because everything else on this page is a weight applied to it.
This is why a downtime percentage is a poor ranking key on its own. A percentage weights every hour equally, and the branch does not. Two branches each losing 2 percent of stated hours can be losing very different proportions of their trade, and the branch with the better percentage is sometimes the one with the worse month.
Why does the platform mix change the answer more than branch size?
Because a listing going dark removes one channel, not the restaurant, and the channels are not equal at every site. A branch where one platform carries most of its delivery loses most of its delivery when that listing fails. A branch where the same platform carries a tenth loses a tenth, from the same incident, on the same night.
Chains rarely hold this split per branch, and there is no reason to assume it is uniform across an estate even inside one city. We do not measure it and cannot supply it, because a share of orders is a fact about your sales rather than about the storefront. It sits in each platform’s own settlement reporting, one branch at a time, and assembling it once is what makes every incident report afterwards rankable. The practical consequence is that a report naming the platform but not that platform’s share at that branch cannot be prioritised, because the two facts only mean anything together.
Where do the orders go, and do they stay inside your estate?
That depends on catchment overlap, which is a geography question rather than a brand question. A customer whose address is also covered by a sibling branch may simply be shown the sibling, in which case the order stays with you and the outage costs a delivery fee difference rather than a sale. A customer with no second branch in range is a lost order, and possibly a lost habit.
At least one platform publishes a rule that makes this concrete. Foody’s terms state that areas “are divided by postal code, and the nearest store to the user is displayed”, which means overlap between your own branches is resolved by proximity without any input from you. So the recapture rate during an outage is a property of how your sites are spaced, decided years earlier at property selection, and entirely invisible in any outage report.
Why does the same trigger produce different durations at different branches?
Because the mechanism that ends the state is not the same everywhere, and neither is the person who has to act. Snoonu builds a timer into the pause itself, holding a busyUntil value with a visible countdown, so a branch that pauses itself returns without anybody remembering to. Keeta does the opposite and says so: “Suspended stores remain hidden from customers until manually reactivated.” Careem adds a constraint that can hold a branch dark long past the trigger, refusing status changes with “Outlet status change is not allowed outside operating hours”.
Then there is the part that belongs entirely to the operator. The detection gap, meaning the time between the listing going dark and somebody in the business noticing, varies enormously between branches according to staffing, shift patterns and how closely anybody watches the tablet. The same fifteen minute trigger becomes a twenty minute incident at one branch and a four hour incident at another, and the difference is not the platform.
What was already committed to the hour before it went dark?
Staff and stock, both of which were paid for on the assumption that the hour would trade, and neither of which can be recovered afterwards. That is the part of the cost that does not scale with volume, and it is why a quiet hour lost is not free. The kitchen was staffed for it either way.
Promotional spend can be committed too, depending on how it was bought. Foody separates placement charged “per impression (Cost per Mille – CPM) or per click (Cost Per Click – CPC)” from placement provided “at a fixed fee (Cost Per Placement – CPP)”, and its cancellation terms bill a withdrawing partner “proportionally for the days or the impressions they received”. Delivery priced placement stops charging when nobody is being shown your listing. Time priced placement does not, so the same outage costs a branch on a fixed fee more than the identical outage at a branch on cost per click.
Why do two branches with identical downtime percentages lose different amounts?
Because the denominator is not the same. A downtime rate is a share of the hours a listing said it would trade, so a branch declaring twenty four hours and a branch declaring ten are being divided by very different numbers. Two percent of a twenty four hour schedule is nearly fifteen hours a month. Two percent of a ten hour schedule is six. The percentages match and the losses differ by a factor of two and a half.
The same effect shows up at market level in our own published figures, which is why we publish two bases rather than one. In July 2026 the panel wide Saudi rate of 2.88 percent fell to 0.77 percent once listings that were dark for almost the whole month were excluded, and the mean incident fell from 12 hours 24 minutes to 5 hours. Comparing a trimmed figure with an untrimmed one produces a conclusion that reverses, and the same trap operates between two branches whose schedules differ.
How should a chain rank branches, given all of this?
By weighted lost hours rather than by percentage, using whatever weights you can defend. Multiply the lost hours by that branch’s share of week revenue in the hours the loss fell in, then adjust for that platform’s share at that branch. The result is a ranking that puts the busy Friday failure above the quiet Tuesday one, which is the ordering any operator would choose if asked, and which a percentage never produces.
One boundary is worth stating plainly. Kitchain (kitchain.co) measures availability, not order volume and not revenue, so the hours are ours and every weight applied to them is yours. That is a feature rather than a gap: the hours are a fact about the storefront, the weights are a fact about your business, and mixing them into a single published currency figure would make both less useful. The arithmetic for turning hours into money is at how to calculate what delivery downtime costs your restaurant.