Why two branches on the same street get different delivery zones
Two branches four hundred metres apart can be offered to completely different sets of customers, and restaurant chains usually discover this from a sales gap rather than from a map. The reason is that a delivery area on these platforms is not a radius drawn around a pin. It is a travel time shape that follows the road network, resolved against neighbouring stores by the platform’s own rules, and trimmed by the platform when riders are short. Three mechanisms, none of them under the restaurant’s control, and all three are sensitive to exactly where the door is.
What is a delivery area actually made of on these platforms?
Time, not distance, at least where a platform says so plainly. Talabat’s partner FAQ answers the question “What is the radius of the talabat delivery?” with a number that is not a number of kilometres: “Our delivery radius is set to within a 15 minute drive time from the location of the business or shop.” That is an isochrone, and an isochrone is not a circle. It stretches a long way down a fast road and stops abruptly at anything that slows a rider, so its shape is a property of the street layout rather than of the restaurant.
This is the entire explanation for most same street differences, and it is the one operators find hardest to accept because the two branches look symmetrical from a car. Fifteen minutes of riding from a unit beside a slip road onto an arterial route reaches suburbs that fifteen minutes from a unit behind the same road, on the wrong side of a central reservation, does not. The two shapes share a centre and share almost nothing else.
How can two addresses a hundred metres apart produce different shapes?
Because everything that decides a route decides the shape, and a hundred metres is enough to change all of it. Which side of a divided road the entrance sits on determines whether a rider turns immediately or travels to a junction and comes back. A one way system that runs past one door and away from the other doubles the outbound leg in a single direction. A pedestrianised block, a service road with a barrier, a mall entrance that is only usable from one approach, a bridge, a level crossing: each of these truncates the isochrone in a particular direction and leaves it intact in every other.
The pinned coordinates matter as much as the building. Where a branch sits inside a mall or a tower, the coordinate registered at onboarding may be the centre of the complex rather than the collection point, and the routing engine draws from the coordinate. Two units in one development can therefore be given the same origin, or origins on opposite sides of it, and neither result is visible from any screen the restaurant can open. This is the cheapest thing to get right at launch and among the most expensive to correct afterwards.
Do the two branches draw on the same pool of riders?
Not reliably, and this is where a difference that was structural becomes a difference that moves. Rider supply is managed by area and by hour, and where a platform reacts to a shortage by narrowing coverage it does so for the affected store rather than across the brand. Foody’s business terms describe exactly that power, reserving the right to “temporarily limit the coverage area of the Delivery Service for the Partner’s products in the event of an increased number of orders that make it impossible to deliver new orders to Users in a timely manner, and for the necessary time until it is possible to effectively fulfill orders again”.
Read that against a drive time boundary and the two effects stack. The isochrone is already shortest when traffic is worst, which is peak dinner. Rider scarcity is also worst at peak dinner. So the branch with the more traffic exposed catchment loses ground in exactly the hours that carry its week, while its neighbour, whose catchment sits on quieter residential roads, barely moves. Neither branch is offline and neither has a support ticket to open, which is why this shows up as demand softness rather than as an incident.
When both branches cover a customer, which one is shown?
The platform decides, and at least one publishes the rule. Foody’s terms state that for its placement service “The areas are divided by postal code, and the nearest store to the user is displayed.” A nearest store rule means overlap between your own branches is resolved without you, in favour of proximity, and the branch that loses a district is not closed and is not restricted. It simply is not the answer to that customer’s query.
That produces a specific and misleading pattern in a chain’s own reporting. A branch that opened recently and sits marginally closer to a dense residential block will take volume from a sibling that has traded there for years, and the older branch will look like it is declining. Nothing about the older branch changed. The catchment was reallocated by a rule about distance, and the only place the reallocation is visible is the customer app, address by address.
Can the fulfilment model itself change the boundary?
It can, and two branches of one brand are not always on the same model. Delivery Hero’s shared integration specification, which Talabat runs on, publishes the reasons a vendor may reject an order, and one of them is OUTSIDE_DELIVERY_AREA, described as “Vendor does not deliver to the customer’s address/area”. That reason is scoped to VENDOR_DELIVERY orders only, meaning it exists for orders the restaurant delivers itself. NO_COURIER, described as “Vendor has no courier (drivers/couriers/walkers/etc) available to fulfill the order”, is scoped the same way.
The negative space is the finding. Where the platform delivers, the protocol gives the restaurant no way to say that an address is out of range, because the range was never the restaurant’s to define. So a branch on platform delivery inherits a boundary it cannot see or change, while a sibling running its own riders holds a boundary it sets and can be held to. If one of your two branches was onboarded on a different fulfilment model, which happens routinely across a franchise estate, the two are not comparable and never were.
Why does none of this appear in the merchant portal or the integration?
Because delivery geography is not in scope for either. Talabat’s Partner API publishes its endpoint groups openly and they are Authentication, Catalog, Category, Order, Promotion and Outlet Management. There is no delivery area object, no radius field, no zone identifier and no customer coordinates anywhere in it. Outlet Management is a state machine for the whole outlet, described as the way to “Instantly update and retrieve your outlet’s status (open/closed) and schedule changes”. Open or closed, for everyone at once.
The result is a blind spot with no error message attached to it. A customer outside the live boundary is not shown a refusal and does not complain, because your branch was never among the restaurants their app returned. Nothing reaches the point of sale, nothing reaches the integration, and nothing reaches the portal. The only vantage point from which one branch’s catchment can be compared with another’s is the customer app itself, queried from real addresses at real hours, which is what Kitchain (kitchain.co) captures for coverage.
How do you establish which of the two branches is actually covering less?
By testing the same list of addresses against both branches, at the same hour, on the same day, and repeating it at a second hour. One reading tells you nothing, because a drive time boundary is a moving object and a single quiet afternoon check flatters everything. Two readings separate the two questions that matter: an address offered branch A and not branch B at every hour is a structural difference in the isochrone or the fulfilment model, and an address offered at four but not at eight is a traffic and rider supply effect.
Keep the address list fixed and dated, because the value is in the comparison over time rather than in any single result. A district that quietly stops being offered your branch is the one failure mode in this category that produces no alert, no ticket and no entry in any log you own. Platform by platform detail on how each one draws and defends its boundary is under kitchain.co/aggregators.