Multi-site online ordering: a launch-readiness checklist

A new restaurant location can look ready online while the team is still working out how orders reach the kitchen. Across several sites, the gaps multiply: a collection slot offered after service ends, a local menu change missing from the website, or a promotion applied to the wrong branch.

A multi-site online ordering launch needs a shared standard and a separate sign-off for each location. Our recommendation is to test the complete journey, including the awkward cases, before inviting more customers into it. Use this checklist when opening a new site, changing platforms or extending direct ordering across an existing group.

1. Define what each location is launching

Start with a location-by-location service plan. Record which sites will offer collection, delivery and table ordering, which channels customers will use, and who owns the launch decision. A common brand does not require every venue to offer the same service.

For each site, agree the menu, service hours, preparation assumptions, collection point and customer-support route. If delivery is included, confirm the fulfilment arrangement and operating area. Separate what must work on day one from additions that can wait.

If the channel decision is still open, our restaurant website and app guide covers that earlier step. This checklist starts once you know what you intend to launch.

2. Check the local configuration, not just the master menu

Choose one owner for shared menu information and identify who approves local differences. Check prices, modifiers, availability, promotions and service settings against the operation at each venue. Include a branch with a different menu or fulfilment model in testing, rather than checking only the simplest location.

Make allergen information part of this review. The Food Standards Agency guidance for England, Wales and Northern Ireland says distance-selling customers must receive allergen information before completing their purchase and when the food is delivered. Food Standards Scotland also describes these two stages in its distance-selling guidance. Check the rules for your food type and nation, alongside your staff training and kitchen procedures.

A menu filter or order note cannot replace those procedures. Decide how ingredient changes reach the digital menu and how staff respond when a customer needs further information.

food2go’s Ops Console provides central management alongside location-level settings. Confirm which settings your team will use and who maintains them.

3. Follow every route into the right branch

Test the links customers will actually encounter: the venue page, Google Business Profile, social profile, launch campaign and printed QR code. Start on a phone with no saved account or previous branch selection. Check the location, available service and destination before placing an order.

Google’s business-link policies require multi-location action links to lead to the specific location. An ordering link must also let the customer complete that action. A working homepage link therefore does not prove that an individual branch’s ordering link is ready.

For table ordering, test the code at the actual table and confirm where the table identifier appears for staff. Give guests a clear alternative if they cannot use their phone or need help.

4. Trace test orders all the way to fulfilment

Run an agreed test order for every service at every launching site. Check what the customer sees, what the store receives and what the person preparing the food sees. Record the order reference and result so a pass can be distinguished from an assumption.

• Confirm items, modifiers, quantities, price and selected fulfilment time.
• Check the branch, collection details, delivery destination or table number.
• Verify where the order appears and who acknowledges it.
• Follow the order through preparation, handover and the customer-facing confirmation.

Where you use an EPOS connection, verify the exact system and configuration. food2go’s integrations directory states that availability and compatibility are confirmed for each brand, location and implementation. A provider’s name in a directory is a starting point for that discussion, not proof that every workflow is connected.

The Ops Console can also be used to manage orders directly without an EPOS integration. Agree the route your team will actually use, including who watches it during service.

5. Rehearse the exceptions with the store team

A successful standard order is only one test. Walk through an unavailable product, an incorrect branch choice, a customer requesting a change, a delay and an interrupted connection. For each case, decide who notices, who can act and what the customer is told.

Check the available process for pausing or adjusting service when the kitchen cannot meet the promise on screen. Agree how cancellations and refunds are handled in your setup. Do not assume an order-status change automatically completes every related action.

Run the rehearsal with the colleagues who will work the opening shift. Keep a short store guide covering the ordering workflow, customer questions and escalation contacts. A central team signing off a screen is not the same as a local team knowing what to do.

6. Verify loyalty across the locations taking part

If loyalty is included in the launch, test earning and redemption across the participating locations and channels. Confirm eligibility, exclusions and what happens when an order changes. Make the customer-facing explanation match the configured rules.

The Burger Boi customer story describes a September 2026 deployment across 20 stores, with location-specific menus, pricing and promotions alongside one four-tier loyalty scheme. Collection, QR table ordering, delivery through Uber Direct integration and WRS POS form part of that documented setup. It is an example of a configured deployment, not a promise that every rollout has identical requirements.

Keep this stage focused on whether the agreed programme works. Our restaurant loyalty ideas guide covers programme design separately.

7. Set a clear decision to launch, fix or pause

Our recommendation is to pilot with a manageable group of sites that represents the differences across your business. A straightforward collection-only venue may not expose the issues found at a busy branch combining several services.

Before launch, agree the issues that would stop a site going live. These should include incorrect location or order routing, inaccurate allergen information, unresolved checkout failures and a team without a workable fulfilment process. Assign each issue an owner and verify the fix before signing it off.

After launch, review completed orders, failed or cancelled orders, fulfilment problems and support contacts by site and service. Use the measures available in your setup, record reporting gaps and compare equivalent trading periods. A group-wide total can hide a branch that needs attention.

Give store teams a defined review point before the next rollout stage. Expand when the evidence supports it, rather than because the campaign date has arrived.

Bring your real launch scenarios to the demo

food2go supports branded web and app ordering for collection, delivery and QR table ordering, configured around individual locations. The useful next conversation is about your menus, services, existing systems and the exceptions your teams need to handle.

Planning a multi-site rollout or your next opening? Book a tailored food2go demo and bring your location list, service plan and test scenarios. We can discuss the ordering, loyalty and operational setup around your business.