Ask guests to choose a location before ordering or booking when the location changes what they can buy, when they can collect it, or which tables they can reserve. If guests usually know the action they want first, let them choose Order or Book before asking for a location. The important point is to establish the right location before showing options that depend on it.
A good selector makes the choice clear and keeps it visible through the handoff. It also gives guests a way to change their minds without silently sending an order or reservation to another restaurant.
Compare location-first and action-first journeys
A location-first journey starts with a choice such as Downtown or Westside, then shows the ordering and booking options for that restaurant. This works well when regulars identify strongly with a branch, or when menus, hours and reservation rules differ enough that a general screen could mislead them.
An action-first journey starts with Order or Book, then asks for a location when the guest needs one. It can feel more direct when visitors arrive with a single task in mind. Someone looking to reserve a table does not need to sort through pickup options first.
There is also a middle path: show both actions and recognizable locations on the first screen, but require a location before displaying a location-specific menu or booking calendar. Keep the choices distinct. A guest should understand whether a tap selects a branch or begins a task.
Use the matrix below as a starting point. The first column describes what matters most to your guests; the final column identifies a risk to check before committing to the design.
| Situation | Starting journey | Why | Check before launch |
|---|---|---|---|
| Branches have different menus and hours | Location first | Guests see options for the right restaurant early | The menu and hours change with the selection |
| Most visitors arrive to order or book | Action first, then location | The first choice matches the guest's task | Each action asks for location before showing branch-specific options |
| One branch accepts bookings; others do not | Either, with clear availability | Guests can find the eligible branch without guessing | Booking is not presented as available at every branch |
| Guests often follow branch-specific links | Start on that branch, with a change option | The link can remove a redundant choice | The branch remains visible and can be changed |
Gather the inputs from the people who maintain them. Managers can confirm each branch's address, service hours and booking rules. Kitchen or operations leads can identify menu differences and pickup restrictions. Your website provider and ordering or reservation vendors should explain where location data is stored and how it moves between systems. If the answers conflict, settle ownership before designing the selector.
Look at how guests reach the site, too. A link from a branch page may carry a useful location choice; a general homepage link may not. Ask whether branch-specific links are supported and what happens when a link is old or a restaurant is temporarily unavailable. Do not assume a visitor's device location is accurate or available.
Show addresses and availability guests can use
Names alone may not be enough. “Main Street” could refer to a neighborhood, a road or a shopping center. Show a street address alongside each branch name, and use a familiar local landmark where it genuinely helps. On a phone, keep each choice easy to distinguish without relying on a map alone.
Separate the location's identity from the status of each service. A restaurant may be open for dining while online pickup is paused, or it may accept future reservations when no tables are available tonight. Instead of a single unexplained “Open” label, show relevant information such as pickup hours or whether booking is available. If status can change during service, ask the provider how often it updates and what guests see if the status cannot be retrieved.
Hypothetical example: A two-branch restaurant has a Downtown kitchen and a Lakeside dining room. Downtown offers pickup until 8 p.m. but takes no reservations. Lakeside offers pickup until 9 p.m. and accepts reservations. The owner expects many visitors to arrive looking for a specific branch, so a location-first screen is a sensible starting choice.
On that screen, each branch has its address and separate pickup and booking information. A guest choosing Downtown can proceed to its pickup menu but should not be led toward a Downtown reservation calendar. A guest who wants a table can see that Lakeside takes reservations and choose it. If the owner later finds that most visitors start with Book rather than a branch, an action-first version may be easier; the selector still needs to identify Lakeside before displaying its booking options.
Avoid treating an estimated wait or future opening time as a confirmed slot. If a guest selects a pickup time or reservation time, the receiving system should make clear whether that time is actually offered before the guest completes the request. Ask who updates holiday hours and temporary closures, and whether changes must be made in more than one place.
Keep the location clear across handoffs
A handoff happens when a guest moves from the website to an ordering page, checkout or reservation flow. The selected branch should remain obvious at that point. Ideally, the receiving page identifies the restaurant by name and address before the guest commits to an order or reservation.
Ask each provider what information a link can pass, whether the receiving system can change it, and what happens if the selected branch is unavailable. Also ask how a guest returns to the website and whether a branch-specific link still works on mobile. These are questions to verify for your setup, not assumptions to make about every integration.
Using the hypothetical restaurant above, a guest selects Lakeside and taps Order. In a simulated check, open the receiving ordering page and verify that it identifies Lakeside and displays the intended menu. Then return to the website and choose Downtown. Check whether the next ordering handoff identifies Downtown. Do this in a safe test environment or stop before any real submission; do not send a payment, guest message or courier dispatch.
That check can reveal a wrong branch name or a broken link. It does not prove that a live kitchen will receive an order correctly, that status will update during a busy shift, or that every device will behave the same way. If you arrange a live service pilot, agree on its scope with staff and vendors separately, including how any real order is authorized and handled.
Pay particular attention to a guest who changes location after adding an item or selecting a time. Ask whether the system clears the selection, asks for confirmation, or checks whether it remains available. A clear warning is preferable to silently moving an item or time to another branch. If the systems cannot carry the choice reliably, an explicit second selection at the handoff can be safer than an incorrect preselection.
Test the choice, including a change of mind
Before launch, give someone who did not build the site a few tasks on a phone and a desktop. Use branch names and addresses from your actual setup, and watch where the person hesitates. Run these as simulations that stop before a real payment, guest message, reservation submission or courier dispatch.
- Find the right branch. Ask the person to find the location closest to a named landmark. Can they distinguish the addresses without opening several pages?
- Start an order. Ask them to select a branch and reach its menu. Does the receiving page show the same branch? Are the pickup hours relevant to that branch?
- Look for a table. Ask them to find a branch that accepts reservations. Can they tell whether booking is offered before choosing a date and time?
- Change location. Have them begin an order or booking, then switch branches before submitting. Is the new branch clear, and is any earlier item or time cleared or rechecked rather than silently carried over?
- Recover from an unavailable service. In a safe test setup, show a paused or unavailable option if your provider supports it. Can the guest understand the status and choose another branch without starting from an unrelated page?
Write down the expected result for each task before you begin. A useful acceptance rule is specific: the branch name and address match on both sides of the ordering handoff. If a task fails, identify whether the website, ordering system or reservation system controls the problem, then retest after the change. A successful simulation is a useful check, not a guarantee about live service.
For the buying decision, compare how much work each design adds to the guest's task against how reliably it prevents a wrong-branch choice. Review your existing restaurant website and online ordering handoff using the checklist. If you are also considering a rebuild, the restaurant website builder comparison can help frame that wider decision.
Next, bring the failed tasks and your branch requirements to Fleksa. Ask how its website and ordering setup would handle your location handoffs, and confirm current US availability for the configuration you need.
Frequently asked questions
Should every restaurant website ask for a location first?
No. If guests usually begin with an action, let them choose Order or Book first and request a location before showing branch-specific options. A single-location restaurant may not need a location selector at all.
Can a branch-specific link replace the selector?
It can reduce a step if the link opens the intended branch and the guest can see and change that choice. Check what happens when the link is outdated or the branch is unavailable.
What should happen when a guest changes branches?
The new branch should be visible, and any previously selected item or time should be cleared or checked for availability at the new branch. Ask the provider to demonstrate the behavior before relying on it.
