A group with forty locations does not have forty ordering problems. It has one, repeated: a customer arrives, and something has to decide which kitchen is going to cook their food. Most of the work of running a network online sits in that decision, and in everything that has to stay in sync for it to keep being right as stores open, move and change their hours.
One storefront, not a site per store
The usual first build is a website per location. It works for two stores and it stops working somewhere around six. Every opening means another site, another menu to keep current, another checkout to test, another set of tracking pixels that nobody remembers to install. The brand drifts store by store, and the customer who moves across town finds a different experience at the other end.
Multi-store ordering inverts that. A single storefront serves one location or a thousand, on one domain, under one brand, across markets with their own languages and currencies. Locations are records inside it, not separate builds. Opening a store is a row of settings, not a project.
Step one: find the store that can serve this address
Nobody should have to know which of your locations covers their street. The storefront asks once, before the menu: type an address, or share a location from the browser. The answer is not the nearest pin on a map. It is the set of stores that can actually serve that point right now, which is a different question.
That check reads the things the stores themselves control:
- Delivery zones drawn per store, as a polygon or a radius, with their own minimums and fees
- Opening hours and preorder windows, so a store that closed twenty minutes ago is not offered
- Order types each location supports: delivery, pickup, dine-in, or some of them at some hours
- Distance and the estimated time the customer can expect from that location
The store the customer picks then stays picked. It carries through the menu, the checkout, the confirmation and the tracking page, so nobody ends up ordering from one location and collecting from another.
Step two: the menu belongs to the location
Once a store is selected, the catalog is that store's catalog. Products, options, availability, prices and hours come from the location, not from a generic list with a disclaimer under it. A dish that ran out at lunch is out at that store and still available three neighborhoods away.
That local control sits inside a master catalog you own. Headquarters keeps one menu structure that every store inherits, and decides which fields a location is allowed to override. The store gets the settings that change street by street; the brand keeps the ones that should never change at all.
The hard part of a network is not the storefront. It is keeping one catalog true in a thousand places at once.
Step three: the order routes itself
When the customer pays, the order becomes that location's problem and nobody else's. It lands in that store's queue in Ordering Merchant, prints or appears on the kitchen display the way that store works, and is handed to a driver in the Driver App or to a third-party delivery partner when it is ready.
It reaches the store's point of sale through the same integration every other location uses. That is the part that saves the year: because stores, menus, zones, customers and payments are one shared model, a new location does not need a new integration with the POS, the payment gateway, the loyalty program or the delivery network. It inherits them.
Order path: check the customer address against store zones and hours, select one store, then route the order to that store's Merchant App, POS and driver. One order, one location, one path through the network.
What headquarters keeps, and what the store keeps
The split is worth writing down before you build. Headquarters usually keeps the master catalog, the brand, the checkout rules and the reporting across the network. The store keeps hours, availability, delivery zones, order types and the on-off switch it needs on a bad Friday. Franchisees see their own locations; headquarters sees all of them, from the same data, without asking anybody to send a spreadsheet.
Get that boundary right and a network of any size behaves like one business online. Get it wrong and you are back to forty ordering problems, one per store.