A manager can inspect a kiosk menu before assigning it to live devices by reviewing a draft in a safe test environment, then checking the same draft on a staged device if the system supports it. The important condition is that neither check publishes the menu, takes a real payment, sends a guest message, or dispatches a courier.
Ask the vendor to show exactly how a draft is separated from the menu guests currently see. Some systems may offer a preview, a test mode, device-level assignment, or a combination. The names matter less than the controls: can you see the intended menu, keep it off live devices, approve it, and restore the prior version if needed?
Who makes the decision, and what are they approving?
Pick one person to own the release. In a single-location restaurant, that might be the manager on duty. In a group, a central menu owner may prepare the changes while a location manager checks the device. Either way, one named approver should decide whether the menu is ready for guests.
The approval should identify the menu version, the devices or locations intended to receive it, and the planned release time. A general message such as “menu looks good” is not enough when several drafts or locations are involved. Record any known exceptions, too. For example, an item may be intentionally unavailable at one location while remaining active elsewhere.
The operational risk is immediate. A missing category can hide an entire part of the menu. An unavailable item that still accepts orders creates a conversation at the counter and possibly a refund. A wrong price can force staff to explain a difference between the kiosk and the price the restaurant intended to charge.
Keep menu approval separate from broader setup decisions. Your restaurant management software and restaurant POS system may be part of the workflow, but ask which system owns each item, price, and availability setting. A correct screen is only useful if the order reaches staff with the intended details.
Choose a safe preview and check the menu
Start with the least disruptive option that lets you inspect the full guest journey. A preview may be enough to check category names and layout. A test mode may also let staff build a simulated order. Ask whether either view uses the actual draft and whether it reflects the settings planned for each location.
A staged device is a kiosk kept out of guest service for checking a draft. It can reveal issues that are hard to spot on a manager’s computer, such as small text, awkward scrolling, or a customization button that is difficult to reach. It is only a safe staging option if the vendor can isolate it from live publication and real transactions. Do not assume that assigning a draft to one device leaves every other device unchanged.
Use both approaches when available: review the draft in test mode first, then inspect it on the staged device. If the vendor cannot isolate a device, use a safe simulation and ask how the guest-facing display can otherwise be checked before release. A staff-only device is not automatically a test device if it still sends real orders.
Work through this checklist before asking for approval:
- Categories: Check names, order, and visibility. Open each category and confirm that items appear where a guest would expect them.
- Unavailable items: Check an item that should not be offered. Confirm whether it is hidden or clearly unavailable and that it cannot be added to a simulated order.
- Price changes: Check the displayed item price and the simulated order total. Include a customization or add-on if its price is changing too.
- Choices and descriptions: Read required choices, optional add-ons, and item descriptions. Make sure a guest can complete a valid selection without guessing.
- Order review: Review the simulated basket for item names, choices, quantities, and totals. Check what information staff would receive without sending a live order.
- Device usability: On an isolated staged device, check screen readability, scrolling, button reach, and the path back to edit an order. Include a staff member who did not build the menu.
For the Fleksa restaurant kiosk, the published product information describes menu browsing, item customization, order review, and possible suggested add-ons. Ask which preview, staging, assignment, and rollback controls are available for your proposed setup.
Use an approval worksheet before release
The following example is hypothetical. A restaurant is preparing a lunch menu draft. The manager expects the lunch category to appear first, a soup to be unavailable, and a sandwich price to change from $12 to $13. A $2 cheese add-on is unchanged. The draft is intended for two live kiosks, but neither should receive it during the checks.
The totals below include the sandwich and cheese add-on only. They exclude tax, payment fees, fixed operating costs, and exception costs such as refunds or staff recovery time. They are menu-check figures, not a cost comparison or a claim about Fleksa’s settings.
| Check | Expected result | Owner and next action |
|---|---|---|
| Test mode: category | Lunch appears first; its items open under the right heading. | Menu owner records the draft identifier and marks pass or sends it back for correction. |
| Test mode: unavailable soup | Soup is hidden or clearly unavailable and cannot be added to the simulated basket. | Manager checks availability; if the soup can be added, the menu owner corrects it. |
| Test mode: sandwich and cheese | The sandwich shows $13; with the $2 add-on, the simulated basket shows $15. | Manager checks both the item and basket prices before approving. |
| Staged device | The same draft is readable and produces the same $15 simulated basket; live kiosks remain on the prior menu. | Shift lead checks the screen; manager confirms isolation and records the result. |
| Release and recovery | Only the two intended kiosks receive the approved draft; the prior menu is identified for recovery. | Manager authorizes release and names the person who will restore the prior menu if needed. |
This worksheet makes the handoff visible. A failed soup check stops approval even if the price and layout are correct. The menu owner fixes the draft, and the manager repeats the affected check on the corrected version. If a correction changes the version identifier, record the new one; do not approve an older result by accident.
Before release, agree on the rollback trigger. For example, the manager may stop use of the new menu if the soup can be ordered or if the sandwich appears at the wrong price. Ask whether the prior version can be restored to selected devices, how long the change normally takes, and how staff can tell which version each device is showing. If version restore is unavailable, agree on a manual recovery: take the affected kiosk out of guest service, correct the menu, and use a staffed ordering point until the manager has checked it.
Approval does not mean the work is over. After release, the shift lead should inspect the live display and report any mismatch to the manager. This is a live service check, not a simulation: avoid placing a real order just to see whether the screen looks right. Follow the restaurant’s agreed recovery procedure if the display is wrong.
Run a vendor acceptance test before buying
Give each vendor the same menu scenario and ask for a demonstration using a draft that will not affect guest service. Agree on pass or fail before the demonstration. A pass requires the vendor to show the result, not merely say that a control exists.
- Separate the draft. Ask the vendor to identify the current menu and a changed draft. Pass if the draft can be inspected without changing the live menu; fail if the demonstration cannot establish that separation.
- Check the exception. Make one item unavailable in the draft. Pass if the preview reflects the intended unavailable state and a simulated basket cannot include it. Fail if it remains orderable or the state cannot be checked.
- Check a price. Change an item price and inspect the item and simulated basket. Pass if both show the intended amount; fail if either is wrong or the basket cannot be reviewed safely.
- Inspect a device. Ask to see the draft on an isolated kiosk or an equivalent safe display. Pass if the vendor can explain and demonstrate its isolation; fail if the only way to inspect the draft is to publish it to a guest-facing device.
- Assign and recover. Ask how an approver selects the intended devices and how staff restore or manually correct a bad release. Pass if the vendor demonstrates a workable release and recovery procedure for your setup; fail if staff cannot identify the affected devices or lack a practical fallback.
Keep the demonstration simulated. It must not charge a real card, send a guest message, or dispatch a courier. Ask support who can help during a failed release, what information they need, and what staff should do while waiting. Also ask which permissions prevent an unapproved employee from publishing a draft.
Compare the answers alongside hardware, installation, payment compatibility, accessibility, kitchen capacity, and staffed fallback—not just the appearance of the menu. The kiosk break-even buying guide can help frame the wider cost decision.
Next step: Take the worksheet and acceptance test to a Fleksa kiosk discussion. Ask the team to confirm feature availability and show how your proposed setup would handle draft inspection, device assignment, and recovery.
Frequently asked questions
Is a menu preview enough to approve a kiosk menu?
It can be enough for some content checks, but it may not show how the menu behaves on a kiosk screen. Ask whether the preview includes the actual draft, customization flow, unavailable states, and simulated basket. Use an isolated device check when available.
Can a manager test a menu without taking a real payment?
Ask for a simulation that stops before any real transaction or communication. Confirm that it will not charge a card, send a guest message, or dispatch a courier. If the vendor cannot provide a safe simulation, agree on another non-transactional inspection method.
What should staff do if the wrong menu goes live?
Follow the agreed recovery plan: identify the affected devices, stop guest use where necessary, and restore the prior menu if that control is available. Otherwise, use the manual correction and staffed fallback procedure, then have the manager check the result.
