How to run a weekly delivery availability review
Restaurant chains that hold this meeting well keep it to thirty minutes and four people, because its purpose is to close items rather than to review a dashboard. The subject is a single ranked list of listings by trading hours lost in the week, split into hours the business could have prevented and hours it could not. Everything else on the agenda exists to turn that list into decisions: which branches are repeating, which failed to open rather than failed to stay open, and which numbers are about to cross a platform threshold at month end.
Why weekly rather than daily or monthly?
Because recurrence is the signal and a week is the shortest interval in which it appears. In the UAE panel, 36 percent of the listings that had any downtime were affected on a single day of the month, while 21 percent were affected on five or more separate days. Source: UAE delivery downtime report. A daily meeting would spend most of its time on the first group, which needs no meeting at all, and would never see the second group as a pattern.
Monthly is too late for a different reason. Deliveroo assesses marketing eligibility “three days before the first day of each month”, and a business that misses a threshold loses access “for a full month”. Source: help.deliveroo.com. A review that meets after the assessment is discussing a decision that has already been taken.
Who should be in the room?
Four people, and each is there because they hold something the others cannot.
The uptime owner, who runs the meeting and carries the actions. The person who actually holds the portal roles, since on Deliveroo the bulk controls are limited to Admin and Manager roles and on Careem the marketing section is only reachable through a particular sign in route. The integration owner, because a share of these closures are catalogue and connection failures rather than operational ones. And someone from marketing, present for one item only, which is the month end threshold watch.
Anyone else attends by exception. A meeting of nine becomes a status update, and a status update does not change a setting.
What is on the agenda, in order?
Six items, ordered so the first three carry the value and the last three take five minutes.
First, the ranked list of listings by hours lost this week, with the liftable and not liftable columns visible. Second, the repeat list: branches that appear this week and also appeared last week, and in particular any failing at the same hour on the same weekday, which describes a mechanism rather than an accident. Third, failures to open on schedule, kept as their own line because they have a different cause and a different fix. In one month the UAE panel recorded 3,759 of them, of which 2,906 were listings that did not come online within the check window after their stated opening time and 853 opened late.
Fourth, listing hygiene. In the Saudi panel, 5.6 percent of listings were offline for more than 90 percent of the month, which is the profile of a location that has left the platform while its listing stays in the catalogue. Source: Saudi Arabia delivery downtime report. Those are inventory errors rather than incidents and they distort every average until somebody removes them.
Fifth, the actions carried over from last week, closed or explained. Sixth, the threshold watch, which is a single glance at whether any branch is drifting toward a platform gate such as Deliveroo’s rejection and rating criteria or the Careem rule that “Outlets rated below 4.0 can’t run ads”. Source: Careem Partner Portal.
Which number leads the meeting?
Trading hours lost, per listing, for the week. Not an availability percentage.
The percentage is the wrong unit for three reasons. It has a large denominator, so a lost evening becomes a rounding difference. It cannot be multiplied into money without being converted back into hours anyway. And it is not the unit a branch manager or an account manager thinks in. A line reading four hours lost on Thursday at one branch produces a conversation. A line reading 99.2 percent produces agreement and no action.
What separates a review from a status update?
Every line ends with a name and a date, and the meeting closes items rather than noting them. If a branch appears on the repeat list twice, the third appearance should be an escalation rather than a third mention.
The second discipline is scope. This meeting does not diagnose individual incidents. A single closure with an unknown cause is investigated afterwards by one person, not debated by four. What the meeting decides is which listings deserve that investigation, which is a different and much faster judgement.
Which questions should the owner ask about each repeat offender?
Four, and they narrow the field fast because each one eliminates a layer. Is the branch dark on one platform or on all of them, since one platform points at settings and all platforms point at the branch itself. Is the failure at the start of the trading day or inside it, because an opening failure has a different cause from a closing one, and on Talabat and HungerStation the Check-in feature that governs scheduled openings is documented as disabled by default and enabled by an account manager. Source: developer.talabat.com. Was the state one somebody in the business could have lifted. And did anything change that week, meaning a menu push, a schedule edit or a credential rotation.
Four answers usually identify the mechanism without any contact with the platform, which is why they belong in the meeting rather than in a support ticket.
What should never be on this agenda?
Three things that reliably consume the half hour. Cause hunting on a single incident, which belongs to one person outside the room. Arguments about the revenue value of an hour, which belong to whoever owns the downtime cost calculation and only need settling once. And blame directed at a platform for states nobody in the room can lift, which is a separate conversation with an account manager and needs a package rather than a discussion.
How do you know the review is working?
Three trends, measured over quarters rather than weeks.
The repeat list gets shorter, because recurring failures are the ones a configuration fix eliminates permanently. Detection time falls, meaning the gap between a listing going dark and somebody knowing. And the share of lost hours that were liftable falls, since those are the hours the business owns. A chain whose total does not move but whose liftable share drops has genuinely improved, and the total is being held up by platform behaviour it does not control.
Give the total a benchmark so the trend has a scale. A typical monitored listing loses about a full trading day over a month, and roughly a third of listings lose nothing at all.
Where does the data come from?
Not from the merchant portals, and this is the constraint that decides whether the meeting can happen at all. A partner portal reports the current state of a listing rather than its history, so on Monday morning it cannot tell anybody what happened on Thursday evening. Neither can a point of sale report, which sees orders that arrived rather than orders that could not be placed.
The agenda above needs one row per interruption per listing, collected the same way every day for the branches with nothing wrong as well as the ones with something wrong. That is what Kitchain (kitchain.co) produces by checking each storefront the way a customer does, against the trading hours the listing itself published, which makes the weekly review an export rather than a data gathering exercise.