Multi-location ordering is a control problem: the customer must reach the correct branch, the menu and price must reflect that branch, the order must enter the right kitchen and financial reporting must preserve location-level responsibility. Copying a single-site setup across several branches without governance creates silent errors.
Choose the location before promising the order
Use address, postcode, collection choice or a clearly selected branch to resolve the location. Explain when areas overlap and what happens if a branch is closed or overloaded. Do not silently reroute an accepted order to another site with different menu, price or timing.
Define central and local ownership
| Area | Possible central control | Local control that may remain |
|---|---|---|
| Menu structure | Item IDs, naming and allergen governance | Availability and supported local items |
| Pricing | Policy and approval | Approved local price where justified |
| Promotions | Terms, budget and code design | Capacity and participation |
| Delivery | Zone standards and reporting | Local travel time, drivers and exceptions |
| Support | Escalation and reporting | Immediate order investigation |
Use stable location and menu identifiers
Every order should retain location ID, menu version, price and channel. Item IDs should be consistent where the product is genuinely the same, with clear handling for local variants. Avoid using branch name text as the only key.
Route each status correctly
- Customer selection and location validation
- Payment and acceptance by the correct legal or operating entity
- POS/KDS/printer destination
- Delivery zone and driver model
- Refund and support ownership
- Settlement and accounting location
Plan overload and closure
A central system must understand local capacity. If one branch pauses delivery, show the customer an honest alternative rather than routing automatically. Test emergency closure, reopening, sold-out propagation and pre-orders.
Measure branch and network performance
Report order, contribution, timing, refunds and complaints by location and channel. Keep network-wide totals, but do not allow a strong branch to hide a failing integration elsewhere.
Govern change
Use named owners, approval, preview, staged release and rollback for menu, pricing, promotion and routing changes. Keep an audit trail and verify that local staff know which settings they can alter.
Practical next step: draw the full order route for two branches with overlapping delivery areas. Mark every point at which the location can be selected, changed or lost, then build test orders for those points.
Design support and refunds by location
The central support team needs access to the relevant branch evidence without unrestricted access to every customer record. Define which branch can authorise a remedy, how marketplace cases are assigned and how a refund reaches the correct merchant account.
Test network-wide failure
Run scenarios for one branch offline, a global menu update failing at one site, an overlapping postcode, a pre-order after a future closure and a central promotion exceeding local capacity. Confirm that the system fails visibly rather than silently routing to the wrong kitchen.
Keep location-specific fallback instructions. A network-level dashboard is useful, but the shift team must know how to operate when central services are unavailable.
When a branch opens or closes, update discovery pages, ordering links, marketplace settings, support scripts and reporting dimensions together. A location is not fully removed while any public route can still send it an order.
Related guides
- Online Ordering — the main guide for the wider topic.
- How to Migrate Ordering Platforms — a detailed next step for putting this guidance into practice.
- Multi-Location Restaurant Ordering Systems: What Changes — a detailed next step for putting this guidance into practice.
- Marketplace Operations — a closely related operational control to review alongside this page.
- Online Compliance and Food Safety — a closely related operational control to review alongside this page.
- Cross-Channel Operations — a connected decision that can change the recommended approach.
