How to prove a delivery app closed your restaurant, not you
Restaurant chains lose this argument for a structural reason rather than a factual one, because the party that closed the store also owns the only record of it happening. Proof therefore comes from two directions at once. Some platform side states prove themselves, since the platform has published that only it can lift them, and an operator who could not reverse the state has demonstrated which kind it was. Everything else needs an independent observation taken while the storefront was actually dark, because the portal will show the current state rather than last Tuesday’s.
Which states prove themselves?
The ones a restaurant is documented as unable to reverse. In those cases the inability is the evidence, and it is published by the platform rather than asserted by you.
Deliveroo’s Forced Closure is the cleanest example. Its changelog states that the tool “can only be enacted by Deliveroo” and that a partner “will not be able to open the site from their side”, and the API returns the closed period with a reason of FORCED_CLOSURE and rejects an attempt to change it with the message “This closed period can only be updated by Deliveroo.” Source: api-docs.deliveroo.com. Careem’s portal shows the same shape as a tooltip, “To reactivate your outlet, please reach out to Careem”. Keeta describes a platform override in which “Delivery service can only be restored when the platform lifts the suspension”. Source: api-docs.mykeeta.com.
For these, the case is made by quoting the platform’s own documentation next to the timestamp. Nobody has to accept your interpretation of a screenshot.
Which closures cannot be proved from the platform’s own record?
The ones where two different events share a single label, and there is a well documented example. Deliveroo’s Site API lists among its refusal reasons the case of a restaurant closed because “they experienced three auto-rejections within 15 consecutive minutes”, and returns that as CLOSED_PERIOD. The same code is returned when a partner deliberately scheduled a day off. Source: api-docs.deliveroo.com. An automatic closure and a planned one are the same string in the record.
The reason vocabulary is thin elsewhere too. Talabat publishes a closed_reason set that includes a bare CLOSED and an OTHER alongside the specific values, and documents that the field “will be omitted if the vendor status is OPEN”. Source: developer.talabat.com. On Careem the list of reasons an outlet can be taken offline is served from the back end rather than published, so an operator cannot audit the vocabulary that describes their own closures.
Where the label is ambiguous, the argument has to be made from timing and pattern instead, which is the second half of this page.
Why does the burden fall on the restaurant at all?
Because nothing in these agreements puts it anywhere else. None of the platforms we read publishes a duty to notify a restaurant that it has been switched off, and at least one disclaims availability outright, with noon Food’s supplemental terms carrying a clause headed “No Service Guarantee”. A party with no obligation to tell you has no obligation to keep the record either.
The practical consequence is that the evidence has to exist before the dispute does. Nobody reconstructs an outage after the fact from a merchant portal, because the portal is a live view. A chain that starts gathering proof when the argument starts has already missed the only window in which the proof existed.
What makes an outside observation hard to argue with?
Six properties, and they are worth being specific about because vagueness is what gets a record dismissed.
It is taken from the customer view rather than the partner view, at a delivery address the branch actually serves, since a listing can be present and unorderable at a given address. It is timestamped in the branch’s own timezone. It is compared against the trading hours that listing itself published, so a store closed on schedule is never counted as an incident. It is confirmed by a repeat check before being treated as real, which removes single failed loads. It handles overnight trading, because a store open past midnight owns the early morning hours and an outage there has to be capped at the end of its window rather than at midnight. And it is collected identically for every listing, including the ones with nothing wrong.
The last property is the one that carries weight in a conversation. A record that also documents your own faults is not a complaint file. It is a measurement, and it is much harder for the other side to characterise as selective.
What does the record need to contain to be actionable?
One row per interruption, with the branch and platform identified in the platform’s own vocabulary, the stated trading hours for that day, the first minute the listing could not be ordered from, the first minute it could again, the resulting duration capped at the end of the trading window, and the state or label the storefront showed if it showed one.
Add two pattern fields, the hour of day and the day of the week, because they convert a set of incidents into a claim. Across the UAE panel, 21 percent of the listings that had any downtime were dark on five or more separate days of the month. Source: UAE delivery downtime report. Repetition on a fixed schedule is not something either side can attribute to chance.
There is a third field worth keeping and it is the one operators leave out: what you did about it. A row that records the branch was reopened by pressing a switch in the portal has quietly conceded that the closure was yours. A row that records four calls to support and no available action has quietly established the opposite. Recording the remedy alongside the incident builds the ownership argument without anybody having to make it explicitly, and it does so contemporaneously rather than in hindsight.
What if the platform disputes the observation?
Then the useful answer is a control group rather than a louder assertion. The same method, applied at the same minutes, to listings that are not yours on the same platform, settles whether the storefront was reachable at all. If unrelated restaurants were orderable while yours was not, the fault was specific to your listing. If they were dark too, it was not.
That comparison is the one thing a single chain cannot produce from its own estate, because every branch it owns shares its account, its menu and its integration. It requires reading many restaurants on the same platform at the same time, which is the vantage point Kitchain (kitchain.co) is built on.
Where proof is genuinely impossible, what is the fallback?
Pattern, and a narrower ask. Some closures will never be attributable, because the platform assigned them an uninformative code and nobody outside can see the trigger. In those cases stop trying to establish fault for one evening and establish a rate instead: this branch, this platform, this many hours across a month, against the market figure for that market.
That reframes the conversation from blame to configuration, which is where it can actually be resolved. A branch losing several times the market rate has something set wrongly, and the fix is a setting rather than an apology.