The person responsible for the menu should approve what changes, while a designated publisher should control when and where it goes live. For a small restaurant, that may be the same owner. For multiple locations, it may be a menu manager approving the content and a channel manager releasing it. Either way, name a second person to check the result.
Before anyone publishes, record the affected items, locations and channels. Then compare that intended scope with what the software will actually send. If the system cannot limit the change as needed, decide whether a manual channel update or a different release plan is safer.
Separate editing, approval and publishing
Start with a list of every place a guest can see the item: the restaurant’s direct ordering site, each delivery marketplace and any location-specific menu. Include the source of each menu, such as the POS or a separate channel dashboard. Two storefronts using the same brand do not necessarily receive updates in the same way.
Assign four responsibilities. One person can hold more than one, but each needs a name:
- Editor: prepares the item name, description, price, modifiers or availability change.
- Approver: checks the business decision and the intended locations and channels.
- Publisher: releases the approved change using the appropriate system or dashboard.
- Verifier: checks what guests can actually see after release and reports differences.
For a single location, the owner might approve and publish, while a shift lead verifies the live menus. A group with several locations may want the local manager to confirm availability before a central menu manager approves. The channel manager can then publish only after the intended scope is clear.
Define what requires approval. A spelling correction may need a quick check, while a price change, modifier removal or availability change deserves explicit sign-off. Also agree on an urgent route: if an ingredient runs out during service, who can mark the item unavailable, and who reviews that action afterward?
Do not assume that an edit permission is separate from publishing permission. Ask whether a user can save a draft without affecting a live menu, whether another user can approve it, and whether publishing can be restricted by location or channel. If the answer is no, use a documented manual approval before the person with access makes the change.
Compare controls against your actual setup
Ask each provider to demonstrate the full path for one of your menu changes, using the POS, locations and channels you intend to connect. A preview of one storefront is useful, but it does not establish what every connected storefront will receive.
Review these controls separately:
- Scope: Can the publisher select individual locations and channels, or does an update apply to a wider group? What happens to channels that should remain unchanged?
- Preview: Can the approver see the item, price and modifiers as they will appear for each intended destination? Which views require a separate dashboard?
- History: Can staff see who changed and published an item, when it happened and what the prior values were? Can they export or copy that record?
- Permissions: Can editing, approval and publishing be assigned separately? Can access be limited to a location?
- Recovery: Can a publisher restore a prior version, or must someone re-enter the old values and publish again? How are partial updates identified?
Mark each answer as supported in the demonstrated setup, handled manually, or unresolved. For example, a channel manager might need to inspect a marketplace dashboard because the main software does not provide that channel’s guest-facing preview. That can still work if the extra step has an owner and happens before the release is considered complete.
Otter describes an Order Manager that consolidates online and manual orders on a tablet, with automatic acceptance and printing and POS connections. Ask separately how its menu publishing and approval controls work for your particular combination; order handling alone does not answer that question.
Fleksa’s restaurant integrations directory distinguishes live connections from those available on request. Availability depends on the restaurant’s setup. If your menu starts in a restaurant POS system, ask where an edit originates and which system has the final say when values differ. The Uber Eats integration is another place to start a conversation about a specific channel, rather than assuming every marketplace behaves identically.
Run a scoped change before relying on the process
The following example is hypothetical. A restaurant has two locations, North and South, and three ordering channels at each: direct ordering and two marketplaces. The owner wants to change the price of a bowl from $12 to $13 at North only, on direct ordering and Marketplace A. South and Marketplace B should retain $12.
The approval should identify all six location-and-channel combinations, not just the two intended recipients. That makes an unintended change visible. The table shows a sample release record and the decisions it supports; the results are illustrative, not the outcome of an actual test.
| Location and channel | Approved result | Sample observed result | Action |
|---|---|---|---|
| North: direct ordering | $13 | $13 | Verifier records match |
| North: Marketplace A | $13 | $13 | Verifier records match |
| North: Marketplace B | $12 | $13 | Publisher restores $12 and rechecks |
| South: all three channels | $12 on each | $12 on each | Verifier records each match |
In this example, the release is not complete when the two intended channels show $13. Marketplace B at North received an unapproved change. The publisher should use the agreed recovery method, and the verifier should check that storefront again. The team should also determine whether the scope setting, a shared menu or a manual step caused the difference before attempting a similar release.
Before a live release, ask for a simulation or safe demonstration that shows the expected destination for the edit. A practice scenario must not charge a real card, send a guest message or dispatch a courier. If an order-flow check is also needed, use a provider-approved test method with a unique test identifier; match the source order to the POS and kitchen result, including modifiers and totals. Keep that order check distinct from verifying what a menu update publishes.
A simulation may not reproduce every live connection. If a safe simulation is unavailable or cannot show a particular destination, record that limit and agree on a controlled live service pilot with the provider. Choose a low-risk change, assign someone to watch every affected storefront, and have the previous values and recovery contact ready. Do not use real customer information in the record.
Keep a release record and a recovery contact list
A shared document or spreadsheet is enough if the software does not provide a complete approval history. Keep one record per change so staff can find the intended scope and prior values without reconstructing a conversation during service.
Include the following:
- Change and reason: item identifier, old and new values, and why the change is needed. Record modifiers and availability as well as price when relevant.
- Scope: every location and channel expected to change, plus those that must stay the same.
- Approval: editor, approver, decision and time. Note any condition, such as waiting for a location manager to confirm stock.
- Release: publisher, planned and actual time, and the system or dashboard used.
- Verification: verifier, check time and observed result for each destination, including unchanged channels.
- Exceptions and recovery: the discrepancy, prior values, person responsible for correction, recheck result and any open decision.
Keep contact details for the publisher, a backup publisher, the affected location manager and the relevant provider or marketplace support team. Decide who has authority to pause further changes and who tells the location when the menu is corrected. If a prior version cannot be restored automatically, the record’s old values become the starting point for a manual correction.
Give every unresolved item an owner and a decision date. For example: “Channel manager to confirm whether North’s Marketplace B can be excluded from a price release before the next menu update.” Until that question is answered, do not approve a release that depends on the exclusion working. Consider a manual update to the intended channels instead, if the owners can verify it safely.
For the broader choice between connection methods, read the related buying guide. Then bring your channel list, approval record and test cases to a Fleksa demo, and ask the team to confirm availability for your restaurant’s location and setup.
Frequently asked questions
Should the person who edits a menu also approve it?
They can in a small operation, but an independent check reduces the chance of an unintended release. If the owner performs both roles, assign someone else to verify each live destination afterward.
Can one menu update be limited to a single delivery channel?
That depends on the software, connection and menu setup. Ask the provider to demonstrate channel-level scope for your actual locations, and check that channels outside the approved scope remain unchanged.
What should staff do if the wrong channel changes?
Have the designated publisher use the agreed recovery method, then ask the verifier to recheck the affected storefront. Record the discrepancy and resolve its cause before repeating the release.
