What to check before a new branch goes live on a delivery app
Restaurant chains treat a delivery app launch as a configuration task and then spend months paying for the parts nobody checked. Four things are cheap to get right before a branch is live and slow or impossible to correct afterwards: the coordinate the delivery area is drawn from, the second and third schedule objects that sit behind the main one, whether the account requires a human confirmation before opening each day, and whether the integration is mapped to this branch and only this branch. Everything else can wait.
What decides the catchment before you can change anything?
The coordinate you hand over at onboarding, because the delivery area is drawn from it and not from the building. Where a platform publishes its rule, the boundary is a travel time rather than a distance. Talabat states that “Our delivery radius is set to within a 15 minute drive time from the location of the business or shop”, which makes the shape a function of the road network around the pin.
That matters most for the sites that are hardest to pin. A unit inside a mall, a tower or a food hall can be registered at the centre of the complex, at a service entrance, or at whichever address the paperwork carried, and each of those produces a different reachable area. Check the pin against the point a rider actually collects from, before launch, and check it on the platform’s own map rather than on the onboarding form. Correcting a coordinate afterwards is an account manager conversation, and every day it is wrong is a district that never sees the branch.
Which schedule objects have to be filled, and not just the main one?
More than one, on the Gulf platforms, and the extra ones are usually left blank at launch. Snoonu’s business hours screen carries tabs labelled “Main Hours”, “Ramadan & Eid Timings” and “Special Hours”, and describes the last as a way to “Add special hours or closures for holidays, special events, or other exceptional events. This will temporarily replace your main hours.” Jahez keeps a separate “Ramadan Hours” object alongside “Business Hours” and offers “Bulk working hours” for setting several branches at once.
A blank secondary schedule is not neutral. It is a decision that will take effect on a date somebody else chose, and it will take effect while whoever set the main hours has moved on. Snoonu also enforces a floor, telling a branch that “Operating hours can not be less than {{hrs}} hours”, so a cautious opening schedule may not be accepted at all. Fill every schedule tab at launch, including the ones for periods months away, and record what was entered outside the platform so the brand has a copy.
Does this account require a human confirmation before the branch opens?
This is the single most valuable question on the list, and the answer differs by platform and by account. Talabat’s Check-in feature requires a partner to acknowledge an upcoming opening up to 30 minutes ahead, and warns that if the partner fails to acknowledge, “the shop will remain closed even if it is scheduled to be open.” Crucially it is not on by default: “By default, this feature is disabled and does not require a check-in status to be sent. To activate the check-in flow, please contact your account manager.” So the correct pre launch action is to ask which state your account is in, rather than to assume.
Deliveroo runs the same idea from the other direction, and a new site is on the strict setting by construction. Its Open Reminder “pops up with sound alerts 30 minutes before your restaurant’s scheduled opening time”, keeps sounding “every 10 minutes until it is acknowledged”, and the published answer to ignoring it is that “your business will stay closed on the app until someone confirms you’re ready to open.” The automatic alternative has a history requirement a new branch cannot meet, since a site needs “At least 95% availability to request Auto-open” and then has to submit a request. A branch in its first months is therefore on manual confirmation whether anyone decided that or not, and somebody in the building has to own the ritual.
Is the branch visible as well as open?
They are different settings on at least one platform, and a launch that only confirms the first will look successful and sell nothing. Jahez runs two independent columns in its branch table, one for open and closed and a separate one headed “Visibility” with the values “Visible”, “Hidden” and “Partially Visible”, plus a preset “Invisible until Tomorrow”. Its certified integrator describes the failure mode directly: “Even when everything is set up correctly, your store may not show up on the Jahez app. Ask Jahez to set your store’s visibility status back to ‘Visible.'”
Confirm the value of that second setting before launch day rather than diagnosing it during one. It is also the setting most likely to be left in a staging state by whoever built the branch record, because it does not appear anywhere in the open and closed workflow that everyone tests.
Is the integration mapped to this branch, and is anyone still using the tablet?
Both halves fail routinely. On the mapping side, Jahez exposes an “Integration Branch ID” alongside “Add/Edit Branch”, and separately a “Partner Credentials” screen holding a “Restaurant ID” and “Restaurant Secret”. The credential screen carries its own warning worth reading before anybody clicks it: “Generating a new key will deactivate the previous one and may affect active integrations.” A new branch is exactly when somebody regenerates a key to fix a connection and takes down a sibling branch that shared it.
On the hardware side, a platform tablet arrives with the branch and works independently of the integration. Deliverect’s guidance for Jahez describes the resulting conflict, where an order fails “when an order was already accepted on the Jahez tablet or dashboard instead of through Deliverect”, and instructs partners to “stop accepting orders on the Jahez tablet or dashboard” once integrated. Decide before opening which channel accepts orders, then physically remove the temptation, because the first busy service is not when that decision gets made well.
How long will a change take once you are live?
Long enough that the pre launch window is the cheapest time you will ever have. Careem publishes its own turnarounds for change requests, listing “Operational hours = 24 hours” and “Menu changes = 7 working days”. Jahez synchronises menus automatically once a day, and according to its integration partner “Jahez has an enabled auto sync everyday at 3 AM, If a manual sync is required please contact your Jahez Account Manager.” HungerStation states that a promotion “can take maximum up to 50 minutes” to appear.
So a menu error found on launch morning is a week on one platform, a discount is most of an hour, and a schedule is a day. Build the launch plan around those numbers rather than around the assumption that anything can be fixed in the moment. Anything the brand cannot itself change, such as the delivery area or the account level features, needs to be raised with the account manager before the branch has customers rather than after.
What should be measured from the outside during the first week?
Whether the listing was orderable during every hour it said it would be. A new branch has no history, which is exactly why the first two weeks are worth measuring closely: they establish whether the schedule that was entered is the schedule the platform is honouring, and they catch a confirmation ritual that nobody is performing. This is the same outside in reading Kitchain (kitchain.co) applies to an established estate, and on a new site it is a commissioning check rather than an alerting one.
Two figures are worth having in mind as context. Across our July 2026 UAE panel, listings failed to come online after a stated opening time 3,759 times in the month, and in 2,906 of those cases the listing did not open within the check window at all. Failing to open is a distinct and common failure from going dark mid service, and a new branch on manual confirmation is the profile most exposed to it.