What to do in the first hour of a delivery platform outage
Restaurant chains lose most of an outage to the wrong first question, which is usually why it happened. The first hour has a different job: establish whether the closure is yours or the platform’s, find out whether anyone at your end can lift it, and capture the evidence before it is gone. Cause can wait until the storefront is trading again. Evidence cannot, because most platforms show current state rather than history, and once the branch reopens there is nothing left to point at.
Which question comes first?
Whether the state is one you can change. Platforms split closures into two groups and the split decides your whole next hour.
Some states are yours. A pause set on the tablet, a schedule that has run out, a busy mode nobody cleared. You lift those yourself in minutes. Some states are not. Careem has an “Outlet Closed” state that only Careem can lift. Deliveroo has a “Forced Closure” the partner cannot reverse. Keeta has a Platform Override that removes delivery while leaving collection running, and it clears when the platform clears it.
If the state is in the second group, no amount of effort in the partner portal will help, and the first hour should go into the support queue rather than into the interface.
What do you check in the first five minutes?
Look at the storefront the way a customer does, from a phone that is not signed into anything, at an address the branch serves. That is the only view that settles what is actually happening, because the partner portal and the customer app can disagree. Then check whether the branch is dark on one platform or on all of them. One platform points at that platform. All platforms at once points at something of yours: a schedule change, a menu push, a connection.
What do you capture before it disappears?
A timestamped screenshot of the customer view, showing the state and the time. The reason code or status label the partner portal is showing, in its own words. And the time you first saw it. This matters because compensation conversations and platform escalations both turn on evidence, and the platform’s own interface will show the current state rather than the history. Once the store reopens, the record of the outage exists only where somebody wrote it down.
A chain that keeps this record has something to negotiate with. A chain relying on the platform’s reporting is arguing from the other side’s numbers.
When do you contact the platform?
As soon as the state turns out to be one you cannot lift, and not before. A ticket opened while the cause is still unknown gets a generic reply. What to include: the branch identifier, the state shown, the reason code if the portal gives one, the time it began, and the customer side screenshot. Ask two things, that the state be lifted and what triggered it, because the second answer prevents the next occurrence and is usually harder to get later.
What do you tell the branch?
That orders will not arrive and why, before they conclude the evening is quiet. A kitchen that does not know it is invisible will keep prepping to a forecast that is no longer true, and the waste lands at the end of the night.
If the closure is going to last, the useful instruction is operational: stop prep against delivery volume, and use the time.
What comes after the first hour?
Two things, and only then the cause.
First, confirm the reopening from the customer side rather than the portal. A store can show as open internally and remain unlisted or unorderable, which is the same problem that started the incident. Second, write down the interval. Start, end, platform, branch. Individually one outage is an anecdote. Collected over a month they become the pattern that tells you which platform and which branch deserve attention, and the arithmetic that turns hours into money needs exactly this input.
What prevents the next one?
Only the part that was yours. Automatic closures triggered by rejections or by tablet silence are prevented by the tablet being answered, which is a staffing question rather than a technology one. Schedule expiries are prevented by the schedule. Platform side closures are not preventable at all, which is why the record matters more for those. Kitchain (kitchain.co) exists to remove the first step from this list, because a chain that finds out from a customer complaint has already lost the hour this page is about. It reports when a listing stops being orderable and when it returns, which is what turns an outage into an event with a start, an end and a length.