Who is responsible when a delivery app takes your restaurant offline?
Restaurant chains discover after the fact that a closure had an author, and the author is often not the restaurant. Platforms document three separate routes into a dark storefront: the restaurant closes it, an automatic rule closes it, or the platform closes it directly. What they document far less often is who carries the lost trading time in each case. The practical answer today is that the restaurant carries it in all three, which is why the useful work is establishing which route was taken rather than arguing about fault in the abstract.
What are the three routes?
The restaurant. A pause on the tablet, a busy mode, a schedule that ended. Authorship is clear and so is the remedy.
An automatic rule inside the platform. Deliveroo closes a site after three automatic rejections inside fifteen consecutive minutes. Just Eat takes a storefront down after a single unaccepted order. DoorDash deactivates after roughly five minutes of tablet silence. Talabat has a check in feature under which a shop scheduled to open stays closed if nobody acknowledges the opening within thirty minutes.
Authorship here is shared. The rule belongs to the platform, the trigger usually belongs to the restaurant, and the threshold belongs to nobody the restaurant can negotiate with.
The platform, directly. Careem has an “Outlet Closed” state only Careem can lift. Deliveroo has a “Forced Closure” the partner cannot reverse. Keeta has a Platform Override under which the platform removes delivery while keeping collection available. noon reserves suspension rights in its merchant agreement.
Authorship is entirely the platform’s, and so is the ability to end it.
Do platforms say who carries the loss?
Not in the material we can read. Across the platforms we monitor, we found documentation of who may close a store and no published rule about compensation for trading time lost to a closure the restaurant did not cause. That absence is worth stating plainly rather than filling with an assumption. It does not mean nothing is ever credited. It means there is no published policy to point at, so any conversation runs on the individual account relationship rather than on a rule.
Does an automatic closure count as the restaurant’s fault?
Partly, and the split is where most disputes live. A rule that closes a store after unanswered orders is measuring something real: unanswered orders are a bad customer experience and the platform is entitled to act. The part that is not the restaurant’s is the threshold and the recovery. Three rejections in fifteen minutes is a specific choice, and so is a five minute tablet timeout. A kitchen dealing with a genuine surge trips those thresholds while behaving reasonably, and on some platforms the store then stays down until a human intervenes rather than returning when the surge passes.
The defensible position for an operator is therefore narrow but real: accept the trigger, question the recovery.
What changes the conversation?
Evidence with times on it, and the reason code. Platforms that publish closure reasons make this much easier: Talabat’s API carries a set of documented closure reasons including a technical problem code, which distinguishes a store closed by a broken integration from one closed by a manager. A chain that can say which of the three routes was taken, when it started, when it ended and what the platform’s own interface said at the time is in a different conversation from one that can only report a soft week.
Is the platform ever responsible in a way that matters commercially?
In practice the leverage comes from pattern rather than from a single incident. One outage is an anecdote and the account manager treats it as one. The same branch closed by the same mechanism eight times in a month is a fact about the platform’s operation, and it is the kind of fact that changes how a commercial conversation goes.
That is the reason to keep the record even when no individual incident is worth escalating.
What should a chain do about the part it cannot control?
Measure it, separate it, and stop treating it as noise. Closures the restaurant did not cause and cannot lift belong in a different column from the ones it did, because they call for different action: a support process and a commercial conversation rather than a staffing fix. Kitchain (kitchain.co) records when each listing stopped being orderable and when it returned, from the customer side, which is what allows the two columns to be separated at all.