Yes, an owner can change one location’s menu without changing another location or channel if the software supports the right local override and publishing controls. Do not assume it does. Ask the vendor to show exactly which fields are shared, where an override applies, and what happens when a shared item changes later.
The buying decision is not simply whether several stores can use one menu. It is whether your team can predict the reach of an edit before approving it, verify the result on each affected storefront, and undo it if necessary. Work through those steps using your own locations and channels before signing.
Map locations, channels, and menu ownership
Start with a list of every physical restaurant and every place a guest can view its delivery menu. That might include the restaurant’s direct ordering site and separate marketplace storefronts. A store with three channels has three guest-facing views to account for, even if all three start from the same menu.
Next, identify who should control each kind of change. An owner or central menu manager may set item names and descriptions for the brand. A location manager may need to change local availability or price. A channel manager may need to handle a restriction that applies to one marketplace. Those are business requirements, not proof that a particular system offers those permissions.
For each location and channel, record the menu source, the person allowed to edit it, and who approves publication. Also identify anyone who can change the shared source itself. A local manager’s permissions may be limited, but a central edit could still reach that manager’s storefront.
Use the table below as a starting worksheet. The entries are a hypothetical example, not a description of a particular product. The goal is to expose the desired boundaries before asking a vendor to demonstrate them.
| Store and channel | Desired menu source | Allowed editor | Approval needed |
|---|---|---|---|
| Downtown, direct ordering | Shared menu with local availability | Downtown manager for availability | Central menu manager |
| Downtown, marketplace | Shared menu with channel restrictions | Central menu manager | Central menu manager |
| Westside, direct ordering | Shared menu with local price | Westside manager for price | Central menu manager |
| Westside, marketplace | Shared menu with local price and channel restrictions | Central menu manager | Central menu manager |
The worksheet separates what the restaurant wants from what the software can actually do. For example, if Downtown needs to mark an item unavailable only on direct ordering, ask whether that exact combination of location, channel, and field can be edited independently. A broad “multi-location menu” demonstration is not enough.
Include the system where staff already maintain items. If your restaurant POS system is the source of menu data, establish who can change it there and whether an edit flows into online menus. If another tool owns the menu, ask how conflicting POS and menu edits are resolved.
Inspect what each storefront inherits
Ask the vendor to trace an item from its shared source to each storefront. Review fields separately: name, description, price, availability, image, modifiers, and any category placement that matters to your operation. A system may let you override one field locally while another remains shared. The answer can also differ by channel.
For each field, get a clear answer to four questions:
- Which locations and channels inherit this value now?
- Can a location or channel override it, and who has permission?
- If the shared value changes later, does the override remain or get replaced?
- How can staff see the affected storefronts before publishing?
Also ask whether the inheritance relationship itself can be changed. For instance, can Westside stop inheriting the shared price while keeping the shared description? If that is possible, ask what happens to its current value and future central updates. If it is not possible, the team may need a separate menu or a different operating process.
Pay particular attention to modifiers. A shared sandwich may have a local price, but its add-ons or required choices could still come from a shared group. Changing a group can have a wider effect than changing the sandwich itself. Ask the vendor to show the dependency, not just the item editing screen.
Channel rules deserve their own check. Ask whether a channel accepts each field, whether a channel-specific edit is retained after a shared update, and how the system reports a rejected or incomplete update. The restaurant integrations directory can help identify connection options; confirm the status and setup for each restaurant and channel in your purchase discussion. A listed connection alone does not establish how menu inheritance works.
Document any boundary the system cannot enforce. If store managers can edit shared prices but cannot be restricted to their own location, decide whether central review is workable. If a local override is essential during service and requires a vendor support request, that delay may make the setup a poor fit.
Test one isolated change and its dependencies
Ask for a demonstration using a fictional item in a sandbox or another agreed test environment. Use the four storefronts in the worksheet as the comparison set. The test should not trigger a real payment, guest message, or courier dispatch. A preview is useful, but it is not the same evidence as the result after publication.
- Record the starting state. Capture the fictional item’s price, availability, description, and modifiers in each test storefront. Note which values are shared and which are local.
- Set the intended change. Make the fictional item unavailable only for Downtown direct ordering. The other three storefronts should retain their starting availability.
- Review the scope before publishing. Have the vendor show the edit permissions, affected-store list or equivalent view, and preview. Record what the screen says will change.
- Publish within the test environment. Compare the resulting guest-facing view at all four test storefronts, including those intended to remain unchanged. Capture the result and time for each view.
- Restore the starting state. Use the proposed rollback method, then check all four views again. Record whether restoration required another approval or publication step.
If the vendor cannot provide a published test storefront, record the preview as preview evidence only. Ask how a controlled live service pilot would be approved and observed before any real menu change. A live pilot is a separate decision from a simulation; it can affect actual guests and requires an agreed recovery plan.
Run a second simulated check on the shared dependency that matters most to your restaurant. For example, change a fictional shared modifier and see whether each location and channel receives the intended result. Then test what happens to an existing local override when the shared value changes. The aim is to find out whether the boundary holds after routine maintenance, not just when the override is first created.
A passing result means the actual test views match the stated intent: Downtown direct changes, while the other three do not. If a marketplace test view is unavailable, do not mark that channel as passed. Ask what evidence the vendor can provide and what remains to be checked before rollout.
This menu-scope exercise complements the separate question of how orders reach the kitchen. For that decision, see the related buying guide.
Approve changes with a scope and rollback record
Turn the test into a repeatable change record. Each request should name the item and fields, the intended edit, the affected locations and channels, and the storefronts expected to stay unchanged. Include the requester, reviewer, planned publication time, and the person responsible for checking the result.
Write down the rollback before approval. Is it a saved previous version, a reversal of the local override, or a manual re-entry of the old values? Who can perform it, and does it need to be published separately to each channel? Keep the previous values and any relevant dependencies in the record so the person on duty has something concrete to restore.
After publication, attach evidence for every relevant storefront: the view checked, the time, and what it showed. Record exceptions rather than treating a missing view as confirmation. If a change reaches an unintended store, pause further related edits, follow the agreed rollback, and recheck both the intended and unintended views.
Use the results to choose a workable operating model. A shared menu with field-level local overrides is attractive when it demonstrably preserves the boundaries you need. A separate menu may be more manageable when the vendor cannot isolate a critical price or availability change, but it can create more upkeep for common items. If neither approach gives your team a reliable approval and recovery process, keep evaluating rather than assuming staff will catch every propagation error.
Next, request a demo with your restaurant’s devices, channels, and test scenarios. Bring the completed worksheet and ask the vendor to run the isolated edit, shared-dependency check, and rollback while your intended reviewer watches. Use Fleksa’s restaurant POS system page to start the conversation.
Frequently asked questions
Can a shared menu have different prices at each location?
That depends on the software and its setup. Ask whether price can be overridden by location and channel, and whether a later shared-price edit preserves the override.
Is a menu preview enough to approve a change?
A preview helps review the intended scope, but it does not prove what a published storefront shows. Compare published results in an agreed test environment where available, and identify any views that could not be checked.
Who should approve a local menu edit?
Choose someone who understands both the location’s needs and the shared menu’s reach. Define which edits a local manager can make alone and which require central review, then confirm the software can support that process.
