To publish a new online menu without showing guests a mixture of old and new choices, prepare the full set of changes together and decide how it will become visible. If your ordering system cannot publish the set as one change, consider temporarily pausing online ordering while an owner makes and checks the updates.
First, ask what happens to open carts and orders already submitted. Then give one person authority to release, verify, and, if necessary, roll back the menu. A short ordering pause may be easier to manage than a guest ordering an old entrée with a new option group.
Inventory every affected item and option group
Start with a change list, not the live menu editor. Include items being added or removed, names, descriptions, prices, photos, availability hours, and every option group attached to an affected item. Options are easy to miss because one group may be shared by several dishes.
Ask the kitchen lead which ingredients, portions, and substitutions are changing. Ask the person responsible for pricing to approve item and option prices. The ordering administrator should map those decisions to the online menu. If different people handle the website, POS, or delivery channels, include them too; a change in one place may not update another.
For example, a new bowl may replace an old bowl while both use a shared protein group. Changing that group could also affect salads that are staying on the menu. List those salads as affected, even if their names and base prices are unchanged. Check required choices, minimum and maximum selections, default choices, and whether an option is available at the same times as its parent item.
Use a worksheet like the one below. This hypothetical release replaces one bowl and changes a shared protein group. The final column makes clear who must confirm each dependency before the release.
| Change | Old state | New state | Check and owner |
|---|---|---|---|
| Bowl | Garden bowl on sale | Harvest bowl replaces it | Kitchen lead confirms ingredients and availability |
| Protein group | Shared by bowl and salad | Revised choices and charges | Menu administrator checks both parent items |
| Guest-facing details | Old description and image | New description and image | Manager approves wording and photo |
| Ordering channels | Old menu visible | New menu visible | Channel owner checks each ordering entry point |
Also record where the current menu can be recovered. Can the system save a version or export a usable copy? If not, keep an approved list of the old settings and images. A screenshot alone may not capture hidden option rules or scheduling details.
Set a release window and name an owner
Pick a quieter period when the kitchen and the person editing the menu can both respond. Avoid a shift change if that means the people receiving orders do not know which version is active. Tell staff the intended window, the expected ordering pause if any, and who can extend it.
The release owner should coordinate the work, even if someone else enters the changes. Give that person a simple decision: publish when the required checks pass; keep ordering paused or return to the previous menu when they do not. Make a second person available to check the guest view independently.
Ask your provider how publishing works before choosing the method:
- Can a complete menu version be prepared privately and published together, or do edits become visible one at a time?
- Can changes be scheduled, and do item hours or channel settings override that schedule?
- Can online ordering be paused without changing in-store ordering? What message will guests see?
- How long can updates take to appear at each ordering entry point?
If the system supports a private version and a coordinated publish, agree on what belongs in that version and check it before release. Do not assume that a scheduled item, a linked website, or another sales channel follows the same switch.
If edits appear individually, a pause provides a controlled window to make them. It also means guests cannot place online orders during that period, so staff need to know how to handle calls and when to direct guests back online. If pausing is not possible, ask whether the provider can offer another controlled release method. Do not depend on a fast sequence of manual edits to keep a mixed menu out of view.
Check the routes guests actually use, including the ordering link on your restaurant website and any direct links staff share. Your restaurant online ordering setup may have its own publication controls; ask how they apply to your configuration.
Test prices and shared options before release
Build a short set of checks around dependencies, not just a visual scan. For each changed item, verify the base price, required selections, available add-ons, and the final amount shown before checkout. Then check an unchanged item that uses a changed group. Confirm that kitchen-facing names or instructions are understandable to the people preparing the food.
In the hypothetical bowl release above, suppose the Harvest bowl has a $12 base price and a chicken option adds $3. The expected item subtotal for that selection is $15. That example includes the base item and selected option only; it excludes delivery charges, payment processing, tax, other fixed costs, and exception costs. It is a menu arithmetic check, not an estimate of order cost or profit.
Check a second path: select the salad that also uses the protein group. Is chicken offered there, and is the displayed charge the one approved for that dish? If the salad should retain a different set of choices, the team may need a separate group rather than editing the shared one. The decision depends on how the menu is configured.
Use a preview or provider-approved test environment where available. A practice check should not charge a real card, send a message to a guest, or dispatch a courier. Ask how to simulate the complete order flow safely, including any kitchen ticket or integration, before trying it. If a safe end-to-end simulation is unavailable, check what you can without submitting an order and agree on a monitored live-service check after publication. A live check is not a simulation: use only a provider-approved method and have staff ready to handle any actual order it creates.
Record a pass or a specific correction for each check. For example, “salad still shows the old protein charge” is more useful than “menu looks wrong.” Fix the underlying group, then repeat checks for every item that uses it. For broader questions about ordering controls and integrations, see the online ordering buying guide.
Manage active carts, release checks, and rollback
An open cart is different from an order the restaurant has already accepted. Ask whether an open cart keeps its original items and prices, refreshes to the new menu, or requires the guest to start again. Also ask whether pausing ordering prevents an existing cart from being submitted. The answers determine whether the team should wait, warn guests through an available ordering notice, or use another provider-supported process.
For accepted orders, keep the details staff need to fulfill what was submitted. Brief the kitchen on how to recognize an order from the old menu and who will resolve an unavailable ingredient or unclear option. Do not assume that reverting the menu will change orders already placed.
Before release
- Approve the complete change list, including shared groups and affected channels.
- Save a recoverable old version or document the settings needed to restore it.
- Confirm the release window, owner, backup checker, and staff instructions.
- Run safe preview checks for prices, option rules, hours, and kitchen-facing details.
- Agree on the pause method, cart handling, rollback trigger, and guest-facing notice where available.
After release
- Open each guest entry point and confirm the new items, descriptions, prices, and options appear together.
- Check affected unchanged items and confirm removed choices are no longer offered as intended.
- Verify ordering is open again if it was paused, and tell staff which menu is active.
- Monitor the first live orders for correct selections and clear kitchen instructions. Escalate discrepancies to the release owner.
Set rollback triggers in advance. A wrong required option or an incorrect price on a popular item may justify stopping online ordering while the team restores the old version. Assign one person to make that call, another to tell the kitchen, and a contact for provider help. After restoration, check the guest view and ordering status again; restoration is a change that needs verification too.
Use this checklist to review your current menu setup with the person who administers it. Then ask Fleksa about direct online ordering, the release controls available for your setup, and verified US availability.
Frequently asked questions
Can I update a menu while guests are ordering?
That depends on the system and its publication controls. Ask whether changes publish together and how open carts behave. If edits appear individually, a temporary ordering pause may be the safer way to avoid mixed options.
What should I do with orders placed before the change?
Keep the submitted order details available to staff and prepare those orders according to what was accepted. Give the kitchen a contact for resolving unavailable items or unclear selections.
How do I know whether rollback worked?
Check the restored menu at each guest entry point, including shared options and prices. Confirm whether ordering is paused or open, and tell staff which version is active. Review already submitted orders separately.
