What a downtime agreement with a delivery platform can and cannot contain
Restaurant operators negotiating this usually aim at the wrong clause. Availability is the one thing these platforms decline to promise, and at least one disclaims it in writing, so a guarantee is not obtainable and asking for it spends goodwill on nothing. What is obtainable is everything around it: which configuration flags are set on your vendors, who at the platform can restore a state out of hours, which identifiers you hold, where a machine notification is sent, and how often the numbers get reviewed. Those are ordinary commitments and platforms grant them routinely.
What do the published partner terms already say about uptime?
They say it is not promised. noon Food’s supplemental terms contain a clause headed “No Service Guarantee”, under which noon and its affiliates “do not guarantee the availability or uptime of the Noon Food Tools or Noon Food Platform” and those “may be unavailable at any time and for any reason”. Source: foodrohelp.noon.com.
The same document shows which direction service levels run. Its clause headed “Service Level Agreements” binds the merchant, requiring an order to be accepted or rejected “within five (5) minutes” and prepared “within twenty (20) minutes”, and states that failure “may result in (a) a temporary or permanent suspension of Merchant’s access to the Noon Food Services and Noon Food Tools”. A separate clause, “j. Suspension of Noon Food Services”, reserves a suspension right “at its sole discretion” on four listed grounds.
Read together, this is a document that measures the restaurant and exempts the platform. Any negotiation should start from that as the baseline rather than from a hope of symmetry.
Is there any published compensation clause to point at?
Not in the material we could read. We went through the published partner terms and developer documentation of the eight platforms we monitor most closely and found no compensation rule for downtime that was not the restaurant’s fault. There is no clause to invoke and no form to submit.
That absence has a practical implication for drafting. A clause you write that assumes a payout mechanism exists will be struck out, and it makes the rest of the document look uninformed. The stronger move is to leave money out and put the effort into the things a platform can grant without a policy change.
What can realistically be fixed in writing?
Configuration, contacts and data, in that order of usefulness.
Configuration first, because these flags decide whether a branch opens at all. Both Talabat and HungerStation document a Check-in feature that is off by default and switched on by an account manager, and that determines whether a scheduled opening requires a human acknowledgement. Source: developer.talabat.com. Ask which state it is in for each of your vendors and get the answer in writing. Do the same for automatic opening on Deliveroo, which is granted on request, and for whether an outlet is catalogue locked because it is point of sale integrated, since Careem’s portal refuses edits on those with a message directing operators to their account manager.
Contacts second. A named escalation route and an out of hours path, because several states are documented as liftable only by the platform. A restaurant that has to find that route during an incident has already lost the evening.
Data third. HungerStation writes of its portal plugins that “you will be given access by your account manager or during registration with us”, and routes vendor identifiers the same way. Source: developer.hungerstation.com. A complete list of your own platform side identifiers is a legitimate and easily granted request, and without it no incident report can be acted on quickly.
Where can a notification actually be agreed?
Only where the platform has already built one. Keeta publishes a webhook called “Store Status Update Notification”, event ID 1102, that fires when a store’s operational status changes and carries the previous and new status. Source: api-docs.mykeeta.com. That is a real destination and it can be written into an integration agreement.
Elsewhere the honest position is that no such duty exists, so what can be agreed is a process rather than an obligation: who your side notifies, how quickly a ticket is acknowledged, and what the platform will tell you about the trigger afterwards. Asking for a duty to warn before a closure is asking for something none of these companies has published anywhere.
Which platform commitments are already published and can simply be cited?
Several, and citing them is cheaper than negotiating them. Careem’s partner FAQ publishes turnaround times of “Operational hours = 24 hours” and “Menu changes = 7 working days”. Source: careem.com. Its portal states that a campaign change “will reflect to users within 5 minutes”. HungerStation publishes that promotion creation “can take maximum up to 50 minutes”. Deliveroo publishes the exact thresholds behind marketing access, “Rejections must be fewer than 8%”, “Star rating must be 3.8 or more” and “Orders prepared late must be fewer than 22%”, assessed three days before the first of each month. Source: help.deliveroo.com.
These are the closest thing to service levels on offer, and they describe the platform’s own processing time or its criteria rather than your availability. Quoting them back is a legitimate way to hold a timeline without asking anyone to sign a new one.
What review cadence should the arrangement carry?
A monthly one, with a stated agenda and a stated data source, because that is the interval at which the numbers become arguable. A single lost evening is anecdote and a month of listings is a rate, and the rate is what supports a request for a configuration change. Fix the date as well as the frequency, since at least one platform runs its own month end assessment and a review that lands after it is discussing a decision already made.
Give the review a benchmark clause too. A typical monitored listing loses about a full trading day over a month and roughly a third of listings lose nothing at all, so agreeing in advance which market figure the comparison uses removes the most common stalling move, which is arguing about whether the number is high.
Which clauses cut the other way?
At least two, and they belong in the same review. Careem states that “Any price modifications are verified and if are found to be higher than your own menu or other delivery platforms could lead to removal from the Careem platform.” Snoonu’s portal warns that special hours left unconfirmed will “result in an indefinite closure”.
Both are removal or closure rights triggered by ordinary administrative neglect rather than by misconduct. A chain reviewing its agreements for downtime protection should read for these in the same pass, because they are the clauses most likely to produce a surprise closure that no monitoring can prevent and no negotiation can undo after the fact.
What makes any of this enforceable?
Measurement that neither party controls. A commitment about configuration is checkable, a commitment about escalation is checkable, and both become meaningless if the only record of what happened belongs to the counterparty.
That is the part a chain has to supply itself. A record of when each listing was orderable, taken from the customer side against the hours the listing published, collected identically for the branches with no dispute attached, is what turns a written arrangement into something either side can be held to. Kitchain (kitchain.co) produces that record continuously, which is what makes a review meeting a reconciliation rather than a discussion.