Our new branch is live but does not appear in the app
Restaurant operators who have just launched a site tend to assume the branch is broken, and in most cases it is present and simply not being offered to the person looking. Live in the portal and visible in the app are two different states, separated by at least six mechanisms that behave differently and fail silently. Work through them in order of likelihood rather than in order of drama, because the two most common answers cost nothing to test and the expensive ones require an account manager. Start with where you are standing.
Are you looking from an address this branch is allowed to serve?
This is the first check because it explains more launch day panics than everything below it combined. A delivery app returns the restaurants that can reach the customer’s address, so a branch checked from head office, from a hotel, or from the wrong side of a boundary is legitimately absent. Where the boundary is a travel time rather than a distance, as Talabat states with its “15 minute drive time from the location of the business or shop”, the shape follows the road network and a nearby address can sit outside it.
Overlap with your own estate matters too, and at least one platform publishes the rule. Foody’s terms state that areas “are divided by postal code, and the nearest store to the user is displayed”, which means a new branch that is genuinely live will still be invisible to any address where an existing branch of yours sits closer. Test from three addresses inside the intended catchment, in the delivery app itself, before concluding anything.
Is the branch open, or merely not closed?
Those are different states, and a new record usually sits in the second. A listing outside its stated trading hours is not offered, and the schedule entered at onboarding is often narrower or later than anybody realises. Careem makes this rigid, refusing status changes with the message “Outlet status change is not allowed outside operating hours”, so a branch that is dark because of its schedule cannot simply be switched on. The schedule has to be edited first.
Then there is the confirmation problem. Talabat’s Check-in feature, where enabled, requires acknowledgement up to 30 minutes before opening and warns that otherwise “the shop will remain closed even if it is scheduled to be open.” Deliveroo’s Open Reminder produces the same outcome, since “If you don’t respond, your business will stay closed on the app until someone confirms you’re ready to open.” Both look identical from the portal, which shows a branch that is supposed to be open, and identical from the app, which shows nothing.
Is visibility a separate switch on this platform?
On Jahez it is, and this is the case that defeats otherwise competent teams because everything they check is correct. The branch table carries two independent columns, one for open and closed and a second headed “Visibility” with the values “Visible”, “Hidden” and “Partially Visible”, plus a scheduled preset “Invisible until Tomorrow”. A branch can be Open and Hidden at the same time, and nothing in the open and close workflow reveals it.
The remedy is not a setting the restaurant changes. Jahez’s certified integrator states it plainly: “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.”” If you are on Jahez and the branch is open, correctly scheduled and reachable, check this column before opening a ticket about anything else.
Has the platform closed the store for a reason on its own side?
Two categories, and they are worth knowing apart. The first is procedural, where the platform is waiting for the restaurant to confirm something. Snoonu’s portal carries an unusually direct example: “Please confirm the special hours for this store by reviewing and re-saving them. Failure to do so will result in an indefinite closure.” A new branch with unconfirmed special hours is therefore a documented route to a store that is closed without anyone closing it.
The second is compliance, and it attaches to the account rather than to the branch. noon Food reserves the right to “defer or suspend activation of Merchant Account or suspend Merchant Account post activation” where it has reasonable suspicion that onboarding documents are “untrue, incomplete, inaccurate and/or invalid”, or that the business is operating outside its trade licence. A branch that never appeared at all, as opposed to one that appeared and vanished, is the profile where a documentation gap is worth checking early, because it will not resolve with retries.
Is the menu the thing that is missing, rather than the branch?
A listing with no publishable menu is not a listing a customer can use, and the failure surfaces at the storefront rather than in the menu tool. Deliverect’s troubleshooting for Jahez names several distinct causes of a failed publish, including that a “Menu publish fails because the store is suspended or inactive”, access errors caused by test and production credentials being confused, and an error that requires a specific setting to be enabled before a brand level menu push will work at all. It also gives the timing, noting that “changes can take 10-45 minutes to take effect”.
So a branch that went live an hour ago and shows nothing may simply be inside the propagation window, and a branch that has shown nothing since yesterday is not. The distinction is worth making before escalating, because the two produce very different conversations with support.
Is the branch absent, or just absent from your search?
They are separate problems with separate causes. A listing that appears when you browse the category and not when you type the brand name is present and not being matched, which is a search behaviour question rather than an availability one. A listing that appears in neither is genuinely not being offered to that address at that moment, which is what everything above is about. Establish which of the two you have before spending a week on the wrong one, because the checks that fix one do nothing for the other.
What should you send, and to whom, once the checks are exhausted?
Send observations rather than impressions, and send them from the customer side. The useful record is a set of dated readings: the addresses tested, the times, the platform, what the app returned for each, and what the portal said at the same moment. That last pairing is the part that ends the argument, because a portal screenshot showing an open branch next to an app reading showing no branch is a contradiction the platform has to explain rather than a complaint it can absorb.
Kitchain (kitchain.co) produces exactly that pairing as a matter of routine, reading each public storefront from the market it serves and keeping the result as a dated series, which turns a launch problem into a documented one within hours instead of weeks. For a new branch the most useful window is the first two weeks, when there is no history to compare against and the commissioning errors are still cheap to correct.