Before buying one ordering platform for multiple locations, test whether each restaurant can run its own service without losing the oversight your central team needs. Give vendors the same scenarios: different menus and hours, a restricted manager account, a pause at one location, and a report that separates results by store.
A website that lets guests pick a location is useful, but it does not answer who can change a menu, receive an order, pause service, or see sales. Start with your current operating setup, then use the matrix below to compare each vendor against it.
Map menus, hours, and order ownership
Make a short operating sheet for every location before a demo. Ask each general manager to supply regular and holiday hours, pickup and delivery hours, menu differences, prices, unavailable items, and the people responsible for changes. Have the person who manages delivery document service areas, delivery arrangements, and any charges. Your central operations lead should identify which details must stay consistent across the group.
Separate guest-facing hours from kitchen operating rules. A restaurant might open for dine-in at 11 a.m. but accept pickup orders only from 11:30 a.m. Another might stop delivery before closing. Ask how the platform handles those differences and what a guest sees when a location is not accepting orders.
Next, identify where each order goes and who owns the response. Does the location receive it directly? Who notices if it is not acknowledged? If a guest calls the wrong store, can staff find enough information to direct the guest to the right one without exposing unrelated customer details? Ask the vendor to show the proposed workflow rather than relying on the location selector alone.
Bring at least one awkward menu case to the demonstration. For example, a shared sandwich could have different prices at two stores, while a third does not sell it. Ask the vendor to show how that difference is set up, who can change it, and whether a central update would affect all three. Then ask what happens when one kitchen runs out of the sandwich during service.
Also check how the ordering experience connects to your restaurant website. A guest should be able to identify the intended restaurant before committing to an order. The operational question is whether that choice carries through to the right menu, hours, and receiving team.
Check permissions and reporting access
List the jobs people actually do, not just the titles on your organization chart. A store manager may need to update local hours and pause ordering. A shift lead may need to mark an item unavailable but not change prices. A central administrator may need to maintain shared menu details and compare locations. An outside bookkeeper may need reports without the ability to change the menu.
For each role, decide what the person should be able to view, change, and approve. Ask the vendor to demonstrate those permissions using separate accounts or a representative demo environment. Include an attempted action that should be blocked: for example, a manager at the north location tries to change the south location's hours. A useful demonstration shows both the permitted action and the boundary.
Ask how access is removed when a manager transfers or leaves. Who can create accounts, reset access, and review changes? If a desired restriction is unavailable, decide whether a different approval process would be workable during a busy shift. A control that depends on one central person being awake and available may become a bottleneck.
Reporting needs the same scrutiny. Ask to see a location-level order report and a combined view for the group. Check whether the report separates sales by location and ordering channel, how refunds or canceled orders appear, and whether the team can export the details it needs. Sales totals are not the same as deposits or processing fees; ask where each appears and how your team would reconcile them.
Give the vendor a question your managers already ask, such as: “Which location had the most canceled pickup orders last week?” See whether the answer can be found without granting every manager access to every store. For broader feature questions, use the online ordering buying guide alongside this location-specific checklist.
Run a location-specific pause scenario
Hypothetical example: A three-location restaurant group wants the east store to stop accepting new pickup orders when its kitchen falls behind. The other two stores should continue taking orders. The east manager should be able to pause and resume that store without changing the group's other locations.
Ask the vendor to demonstrate this in a sandbox or another isolated environment first. Use simulated orders and contact details. Confirm that the scenario cannot charge a real card, send a guest message, or dispatch a courier. A practice check should not touch live service.
- Start with all three locations shown as available for pickup in the demo.
- Sign in as the east manager and attempt to pause new pickup orders at east only.
- View each location as a guest. East should not accept a new pickup order; the other two should remain available.
- Check what happens to a simulated order placed before the pause. Ask who can see it and what staff must do next.
- Resume east and repeat the guest view. Ask who can resume service and whether any confirmation or record is available.
Record what the vendor actually demonstrates and any manual steps. If the platform cannot pause pickup separately from delivery, for example, the decision is whether pausing both fits your operation. Do not count a workaround as a pass unless your team can use it at the required speed and authority level.
A simulation checks the configured workflow; it does not prove that staff will notice an issue during a rush. If the platform passes the simulated checks, plan a separately approved live service pilot with the vendor and the location team. Define the hours, responsibilities, guest communication, and rollback plan in advance. A live pilot can involve real orders, so monitor it closely rather than treating it as practice.
Compare vendors with one test matrix
Use the same locations, roles, and scenarios for every vendor. The matrix below gives each test a practical acceptance target. Mark a result as demonstrated, workable with a documented manual step, or not yet answered; then note who would own any extra work.
| Area | Ask the vendor to show | Acceptance target | Decision if short |
|---|---|---|---|
| Menus and hours | Change one store's price and pickup hours | Only the intended store changes | Estimate the work and error risk of separate updates |
| Permissions | Try a local update and a cross-store update as a manager | Local action allowed; unauthorized cross-store action blocked | Assign an approval process or reject the setup |
| Pause | Pause east pickup in a safe simulation | East stops new pickup orders; the other stores remain available | Decide whether a broader pause is operationally acceptable |
| Reports | Find canceled pickup orders by location | Authorized staff can find the figures needed for their role | Document the manual report or export process |
| Support | Walk through an ordering outage at one store | Staff know whom to contact and what to do next | Check coverage and escalation before signing |
The targets are examples, not universal requirements. If every menu change must be centrally approved, adjust the permission target accordingly. The important point is to agree on the target before the demo and compare vendors on the same terms.
Then compare written quotes and contract arrangements. Ask whether pricing is per location, which services and setup work are included, and whether opening or closing a store changes the commitment. Identify fixed subscription and setup charges separately from variable processing and delivery charges. Ask about exception costs such as additional hardware, menu changes, support outside normal coverage, and cancellation. Get the duration, renewal terms, support hours, and escalation route in writing.
For a Fleksa reference point, the plans page, checked November 2026, lists Fix at $199 per month per location with 0% Fleksa commission on direct online orders. Processing, delivery or dispatch, hardware and add-ons, and applicable sales tax are extra. For three locations, the fixed plan base would be $597 per month before those extras. That is not an all-in operating cost or a quote for your setup. Ask for a current written quote and US availability.
Keep payment processing separate from the rest of the quote: a processing fee describes a payment cost, not the total cost of operating the ordering channel. Likewise, a delivery charge paid by a guest may offset a restaurant expense but remains a cost to the guest. When comparing channels, the guide to direct and marketplace order contribution can help you account for those differences. For contract or tax treatment, consult a qualified adviser.
Next, fill in the matrix for your current setup and choose the two or three failures that would most disrupt service. Use those as acceptance tests in vendor demos, then ask Fleksa about restaurant online ordering and verified US availability for your locations.
Frequently asked questions
Should every location use the same menu?
Not necessarily. Shared items can simplify maintenance, but local prices, availability, and hours may differ. Test how each difference is managed and who can approve changes.
What should happen to existing orders when a location pauses?
Decide your preferred staff workflow before the demo. Ask the vendor to show where existing orders appear and how staff handle them; a pause on new orders should not be assumed to resolve orders already received.
Is a per-location subscription the total cost?
No. Compare the subscription with setup, payment processing, delivery arrangements, hardware, add-ons, applicable tax, and exception charges in a written quote. The mix depends on your operation and agreement.
