Staff can inspect an online menu change before guests see it only if the ordering setup provides a suitable private view, staging environment, or another controlled review method. Ask the provider to demonstrate the exact path from editing to preview to approval. If a change appears to guests as soon as it is saved, agree on a different review process before relying on it.
The buying decision is about more than seeing a menu on a screen. A useful preview lets the people responsible for prices, food preparation, and guest experience check the details that matter without placing a real order or exposing an unfinished item. The checklist below helps you decide whether a provider's process is good enough for your restaurant.
Test the preview and staging options
Start by asking the provider to show a normal menu edit from beginning to end. Have a staff member choose a representative change, such as adding an entrée with a size choice, a paid extra, and a temporary availability window. The demonstration should show who makes the edit, where another person reviews it, and what action makes it visible to guests.
Ask whether the review view is private, who can access it, and whether it uses the same layout and ordering rules as the live menu. A screenshot may help someone proofread a name, but it cannot establish whether a required choice works or whether the final price is calculated correctly. A separate staging menu may allow deeper checks; ask how its settings and content reach the live menu after approval.
If the provider offers a preview link, ask whether it expires, whether access can be restricted, and whether anyone with the link can see unpublished prices. If the review takes place inside an admin account, ask whether reviewers need editing permissions. A manager who only needs to approve a change should know whether they can do so without also being able to alter or publish it.
Define the inputs before the demonstration. The owner or manager supplies the intended selling price and approval rules. The kitchen supplies item names, descriptions, choices, and preparation or availability limits. The ordering lead supplies the channels and devices guests use. The provider explains how those inputs are represented and which parts can be checked before publication.
Also ask what happens when someone edits an item after it has been approved. The safest rule for your team may be to send the changed version back for review rather than assume the earlier approval still applies. Confirm whether the software supports that handoff or whether staff must manage it themselves.
Compare the process and its cost
Compare providers on the work needed to get a correct menu in front of guests, not just on whether a sales sheet mentions a preview. A private, interactive preview may be worth more to a restaurant with frequent specials and complex choices than to one with a short, rarely changing menu. But an elaborate staging setup can also add staff time if every small correction must be entered twice.
Use the same sample change in each demonstration. Ask for a written quote that identifies the ordering plan, setup, any charge for additional users or preview environments, and any recurring add-ons needed for the demonstrated process. Ask which charges are fixed and which vary with usage. Include any quoted support or configuration fees for exceptions, such as rebuilding a menu or restoring an earlier version. Compare the quote totals over the same period and number of locations.
For a reference point, Fleksa's plans page, checked in November 2026, lists Fix at $199 per month per location with 0% Fleksa commission on direct online orders. Payment processing, delivery or dispatch, hardware or add-ons, and applicable sales tax are extra. That plan price alone does not establish the cost or availability of a particular preview workflow; ask for the relevant options and a written quote for your setup.
A practical comparison also counts staff effort. If one option gives the kitchen a readable preview but requires a manager to copy every approved change into the live menu, decide who will check the copy. If another uses the same draft for review and publication, ask the provider to show that the approved version is the one that will appear. Neither approach is useful if the final check falls between two people's responsibilities.
For a broader look at ordering requirements beyond menu review, use the online ordering buying guide. Keep your preview decision separate from questions about delivery coverage, payments, and other parts of the purchase.
Check mobile views and availability conditions
Hypothetical example: A restaurant wants to add a lunch bowl that comes with a choice of protein, an optional paid topping, and a lunch-only availability window. The manager intends to review the change on a phone before approving it. This example describes a desired test, not a claim about any provider's features.
In a private preview or simulation, the manager opens the menu at a narrow screen width and reads the item without relying on the admin editor. Is the name recognizable? Is the description complete? Is the base price visible? Can the guest select a required protein and add the topping? Check that the displayed total reflects the selected options and that the item can be added to a simulated cart.
Then check the lunch window. Ask the provider how to view the menu as if it were inside and outside the intended hours. If the system cannot simulate time or location conditions, ask what evidence staff can review before publishing and what needs a controlled check afterward. Do not assume that a preview on one phone establishes how every device or ordering channel will behave.
Also check the conditions that apply to your restaurant: pickup versus delivery, location-specific menus, sold-out items, scheduled orders, and any minimum or maximum choice rules. A dish can look correct in a list while its choices fail later in the ordering flow. If the provider supplies both a restaurant website and an ordering experience, ask where the menu appears and whether each guest-facing view needs a separate check.
A practice scenario must stay a practice scenario. Confirm that the provider's preview or simulation will not take a real card payment, send a guest message, or dispatch a courier. If an end-to-end live check is necessary after publication, plan it separately with the provider and staff, agree on the handling of any real transaction, and check the menu promptly. A live check can catch issues that a preview cannot, but it happens after guests may already be able to see the change.
Use an acceptance checklist and assign approval
Before comparing demonstrations, agree on what counts as an acceptable preview. The table gives a starting checklist. Adapt it to the menu and mark each requirement as met, partly met, or not met during the provider's demonstration. The final column identifies the decision or follow-up a restaurant should make, rather than assuming every system works the same way.
| Check | What staff should inspect | Acceptance decision |
|---|---|---|
| Privacy | Where the draft appears and who can open it | Unapproved changes stay out of the guest-facing menu. |
| Content and prices | Names, descriptions, base prices, and paid choices | The reviewer can verify the intended details before publication. |
| Ordering flow | Required choices, optional extras, and calculated totals | A simulation checks the relevant selections without a real transaction. |
| Availability | Hours, location, order type, and sold-out treatment | Staff can check each important condition or know which needs a later live check. |
| Approval | Who reviews, publishes, and handles edits after review | One named approver accepts the version that will be published. |
| Correction | How to fix or restore an incorrect published item | The team knows the steps, permissions, and any support needed. |
Give one person final approval for each change, even when several people contribute. For example, the kitchen lead can check ingredients and availability, while the manager checks prices and the guest-facing presentation. The manager then records approval of the specific version and tells the authorized publisher to proceed. If the software has an approval record, ask to see it; otherwise, a dated internal message identifying the item and change can provide a simple handoff.
Decide what happens if the approver is unavailable. Name a backup and give that person the same checklist. For an urgent sold-out item, establish who may make a correction immediately and who will review it afterward. That exception should not become the routine path for adding an entire menu.
Finally, ask the provider to demonstrate correction as well as publication. Can staff hide an item, restore a prior version, or must they edit it again? What permissions or support are required? Keep a copy of the approved item details so staff have something concrete to compare if a mistake appears.
Use the checklist to evaluate your current setup. Then ask Fleksa about restaurant online ordering, including the available preview and approval process and its availability for your US location.
Frequently asked questions
Is a menu preview the same as a staging environment?
Not necessarily. A preview may show a draft menu, while a staging environment may provide a separate place to configure and exercise it. Ask which ordering steps and availability conditions each option can actually simulate.
Can staff approve a menu change without publishing it?
That depends on the ordering system and its permissions. Ask the provider to demonstrate whether review and publication are separate actions and whether an edit after approval requires another review.
What should staff do if there is no private preview?
Ask whether the provider offers another controlled review method. Check the intended content and prices internally, identify what cannot be verified before publication, and plan a prompt live check with a named person ready to correct mistakes.
