Before choosing an online ordering provider, ask to see a complete menu change: create an item with choices, set where and when it is available, send it through the approval process, publish it, and reverse it. Have the vendor show what a guest sees at each relevant location and fulfillment method.
The best editor for your restaurant is the one your staff can use accurately during service, with enough control to keep an accidental change from reaching guests. A long feature list cannot answer that question. A demonstration using your own menu examples can.
Test items, choices and availability
Bring a small menu sample that represents the tricky parts of your operation, not just a list of item names. Include an item with required and optional choices, an add-on with a price, an item that sells out, and one with a description that staff may need to update. The owner or menu manager should supply the intended wording and prices; the people who handle orders should explain what causes confusion in service.
For a hypothetical demonstration, use a rice bowl priced at $12. A guest must choose one protein, may add avocado for $2, and may leave a note. Ask the vendor to build it while you watch. Then try the guest view yourself: can you place the item in the cart without choosing a protein? Does adding avocado make the displayed item total $14? Can you remove the add-on before completing the order?
Those are acceptance checks, not assumptions about a particular system. If the provider cannot show a guest-facing preview without sending a real order, ask for a safe demonstration environment or use a non-transactional preview. Do not enter a real payment or send a test order to the kitchen or a courier.
Next, ask how staff mark the bowl sold out. Does the change hide the item, prevent it from being ordered, or only add a label? Ask to see the exact result in the guest view. Then ask how staff restore it and whether that requires a separate approval. If the item returns automatically at a set time, confirm who sets that time and what happens if the ingredient is still unavailable.
Also check less obvious edits. Can a manager change an add-on price without rebuilding the item? If the same choice appears on several items, can it be edited once, and what else changes as a result? Can staff add a clear description for an ingredient change? A shared edit can save time, but it also makes mistakes wider. Ask the vendor to show the affected items before applying one.
For the broader ordering decision, the online ordering buying guide covers considerations beyond menu editing. Keep this demonstration focused on the work your team will actually do.
Review location and fulfillment differences
A menu that works for one dining room may not work for two kitchens and several order types. Before the demonstration, write down where items, prices, hours and choices should differ. A location manager can identify kitchen constraints; the owner should decide which differences are intentional and who may change them.
Consider a separate hypothetical restaurant with two locations. The downtown kitchen offers the rice bowl for pickup and delivery. The smaller location offers it for pickup only because it cannot pack the dish for delivery. Ask the provider to show how those rules are configured and then open each guest-facing menu. The bowl should be available for downtown delivery and unavailable for delivery at the smaller location.
Now make the request harder: the smaller location needs to mark the bowl sold out for an afternoon without affecting downtown. Can its manager make that change locally? If a central manager changes the bowl description, does that update both locations or only one? Ask the vendor to show the choice and its consequences rather than describing the menu as centralized or flexible.
Compare the work on both sides of the trade-off. A shared menu can reduce duplicate editing when every location follows the same rules. Local menus can give managers more control but may require repeated changes. The useful question is whether the provider lets your team make the differences you need without creating more copies than it can maintain.
Check timing too. If lunch ends at 2 p.m., ask what a guest sees just before and just after that time for each order type. If advance orders are important, ask whether availability is evaluated against the time the order is placed or the requested fulfillment time. Have the provider demonstrate your intended rule; do not assume the two are treated the same way.
Finally, ask where the menu appears. If your restaurant website links to an ordering page, check whether an edit is reflected in the places guests use to browse and order. If another sales channel uses a separate menu or connection, ask who maintains it and how differences are spotted. A change in one editor should not be presumed to update every channel.
Check staff permissions and publishing workflow
A good demonstration follows the people, not just the buttons. Name the roles in your restaurant: perhaps an owner approves price changes, a general manager edits descriptions, and a shift lead handles sold-out items. Tell the vendor which actions each person should and should not be able to perform.
Ask the provider to demonstrate with separate role accounts if possible. Can the shift lead mark an item unavailable without gaining the ability to change its price? Can a manager prepare a price change for the owner to review? If approval is part of your requirement, have the vendor show the pending change, the person authorized to approve it, and the point at which guests see it. A draft or review step should not be assumed just because the editor has user accounts.
Use a concrete acceptance rule: a shift lead must be able to make the bowl unavailable at one location, but must not be able to publish a price change. Watch both actions attempted in a safe demonstration environment. If the provider cannot meet both conditions, decide whether the workaround is acceptable. For example, the owner might handle all menu changes, but that creates a delay when an item sells out during a rush.
Ask what record remains after publication. Can an authorized person see who changed an item, what changed and when? Can they distinguish a saved draft from a live menu? If a mistake is reported, the person investigating needs enough context to decide what to fix, not just a message that an edit occurred.
Keep practice separate from a live service pilot. In a simulation, use a sandbox or preview with no real payment, guest message, kitchen order or courier dispatch. If you later run a live pilot, agree on its scope, staff responsibilities and stop conditions first. Real guest orders need normal handling; a practice scenario should never trigger them.
Use a scorecard and check how changes are reversed
Give each provider the same tasks and record what you actually saw. The table below turns the demonstration into a decision tool. A pass means the provider showed the result under the conditions you specified; a verbal answer alone is a follow-up, not a pass.
| Task | Acceptance check | Record |
|---|---|---|
| Required choice and add-on | Guest must select a protein; the $2 add-on makes the $12 bowl total $14. | Pass, follow-up or fail; note any extra setup. |
| Sold-out item | Shift lead makes the item unavailable at one location; other location stays available. | Record guest view and restoration steps. |
| Fulfillment rule | Item appears for downtown delivery but not delivery at the smaller location. | Record each location and order type checked. |
| Price approval | Shift lead cannot publish a price edit; authorized approver can review it before publication. | Record roles, approval steps and any workaround. |
| Reversal | Authorized person restores the intended menu and verifies the guest view. | Record whether prior values are retained or must be entered again. |
Before scoring, agree on which checks are essential. A single-location restaurant with one menu editor may accept a simpler permission setup. A multi-location operator that delegates sold-out changes may treat location-specific access as essential. Do not let an attractive interface outweigh a failed requirement that would slow service or expose the wrong menu.
For reversal, introduce a deliberate mistake in the safe environment: change the bowl description or price, publish it there, and ask an authorized person to restore the intended version. Does the system offer a prior version to restore, or must staff re-enter the correct values? How many steps does that take? Ask to see the guest view after the correction, not just the editor screen.
Also ask what happens to orders already received with the earlier menu. A corrected listing does not by itself tell staff how to handle an order placed before the correction. Your team needs a procedure to identify affected orders, check their details and decide who handles any guest contact. Do not send a guest message as part of the simulation.
Before committing, get a written quote for the setup and ongoing service you need. Ask whether menu setup, additional locations, staff access or changes carry separate charges, and whether there are limits on support. Compare the operational quote totals on the same scope; processing fees alone are not the all-in cost of running an ordering channel. The guide to direct and marketplace order contribution can help with that separate cost decision.
Use the scorecard on your current setup first, then bring the same menu tasks to each demonstration. To discuss your requirements with Fleksa, ask about restaurant online ordering and confirm availability and setup for your US location.
Frequently asked questions
What is the most important menu edit to demonstrate?
Start with the change your staff must make quickly during service, often marking an item sold out. Verify who can make it, which locations it affects and what guests see afterward.
Should every location have its own menu?
Not necessarily. Shared menus can reduce duplicate work, while location-specific controls can accommodate different kitchens and hours. Test the differences you actually need and the effort required to maintain them.
How can I test menu changes without affecting guests?
Ask for a sandbox or non-transactional preview and confirm that the practice cannot trigger a real payment, guest message, kitchen order or courier dispatch. Check the guest view there before considering a separately planned live pilot.
