Who do I contact when my UK listing goes down?
Restaurant operators reach for support first and lose the evening doing it. The first ten minutes should be spent establishing which of two situations you are in, because the answers are entirely different. Most closures are ones the restaurant can end itself in seconds, and support cannot help with those. A minority are states only the platform can lift, and for those a ticket started at seven in the evening resolves inside the trading day while one started at nine does not. Diagnosis first, contact second.
What do I check in those ten minutes?
Four things, fastest first.
The device: awake, charged, on the network, logged in. This resolves the largest share of incidents and takes thirty seconds by phone to the site.
The state in the portal: is the store paused, closed, in a busy mode, or on special hours somebody set. If there is a state you can clear, clear it and you are done.
Other sites of yours on the same platform: if they are also down, this is not your site and support is the right call immediately.
An address test: if the site appears from one address and not another, it is not down, it is a coverage question, and that is a different conversation entirely.
When is it a platform state I cannot lift?
When the portal shows a closure you did not set and cannot clear, and the wording points at the platform rather than at you.
Deliveroo’s documents describe action it may take including “suspending the provision of our services”. Where a state is applied by the platform, no amount of pressing buttons at the site helps, and the only route is support plus the account manager.
That is the case where speed matters most, because the clock is a queue rather than a task.
Who exactly do I contact?
Both partner support and the account manager, in the same message, and say you have done so.
Support has the ability to look at the account and a queue that will get to it. The account manager has discretion and a reason to care about a site’s trading. Sending to one and not the other is how these get lost.
Give them the site, the listing, the time it started, what you have already checked, and what you are asking for. Four lines. A message that shows the obvious things have been eliminated jumps most of a queue.
What should the site be doing meanwhile?
Nothing to the settings, and everything else normally.
The instinct at a site under pressure is to toggle things, and toggling produces states that are harder to unwind than the original problem. If the cause is not identified, changing settings adds a variable.
Where the outage is genuine and long, moving demand is worth more than fixing it: pushing customers to the other platforms you are on, and to direct ordering if you have it.
Does it matter what time it starts?
More than almost anything else, because closures cluster in the evening and support does not.
On a platform with no automatic reopening, an outage runs until somebody looks at it, so the length of an incident is set less by its cause than by the hour it began. One that starts at ten at night is a whole night unless a person is watching.
Which is the argument for an alert and not a routine: a Kitchain (kitchain.co) message at ten past ten means the ten minute diagnosis at the top of this page happens at ten past ten, and that is the entire difference between a two hour incident and an eleven hour one.
What should I write down afterwards?
The start time, the end time, the cause and who ended it. Four fields.
That record is worth almost nothing for one incident and a great deal after a quarter, because it converts a series of bad evenings into a pattern with a named mechanism. Patterns are the only thing that changes either an internal process or a commercial conversation.