The safest way to review a QR menu change is to inspect the proposed guest view before it becomes public, then have one named manager approve it. Ask whether your software provides a private preview link, a draft view, or another way to see unpublished changes. A scheduled publication can control when a change goes live, but it does not necessarily let you see what guests will see beforehand.
Before buying, demonstrate the exact workflow with an item, a price and the service area where the change should appear. Agree on what happens if any of those details are wrong. If a vendor cannot show a private review, decide whether your team can accept a manual check after publication and how quickly you can correct a mistake.
Decide who owns the menu change
A QR code may open a menu, an ordering flow or both. The review needs to match what your guests actually use. A wrong description can confuse diners; a wrong price in an ordering flow can also affect what a guest is asked to pay. A change assigned to the wrong service area might appear at tables where staff are not prepared to serve it.
Choose one person to make the edit and one manager to approve it. In a small restaurant, the same person may do both, but a second set of eyes is useful for high-impact changes. The approver should know the intended item, price, service area and publication time—not just whether the screen looks tidy.
Write down the current live details before editing. Keep the previous item text and price somewhere the manager can find them, along with the steps for restoring them. Ask whether restoring an earlier version also restores its service-area settings, or whether those must be changed separately.
Also decide how staff will hear about the change. If an item appears on a guest's phone but the dining room team expects a different price or description, the review has missed an operational detail. For the broader service choice, see the guide to where QR ordering fits in table service.
Compare a private preview with scheduled publication
A private preview is useful when the manager needs to inspect the proposed guest experience without changing the live menu. Ask whether the link shows the actual draft, who can open it, how long it works and whether it reflects the relevant service area. A preview that shows a generic menu may not reveal a location or table-specific mistake.
A preview also needs a clear boundary. Can someone with the link place an order or make a payment? Can the link be shared outside the team? For practice, use a vendor-provided test environment or a view that cannot create a real transaction. If the vendor cannot provide one, keep the exercise to viewing and verifying the change.
Scheduled publication solves a different problem: timing. It can be useful when a manager approves a change before service but wants it to appear later. Ask whether the scheduled change can be reviewed, edited or canceled before its effective time, and what time zone the schedule uses. Do not assume that setting a time creates a private preview.
A schedule is a poor substitute for review if the first accurate view appears only after guests can see it. Likewise, a preview is not enough if someone can publish without approval. The strongest workflow for your restaurant may use both, provided the vendor can demonstrate both and your team can manage the handoff.
Use a worksheet for an item, price and service area
The following values are hypothetical. The restaurant wants to change a lunch item called the garden bowl from $12 to $14 and make the revised listing available in the patio service area. The dining room should keep its existing listing. The editor prepares the change; the shift manager approves it. The manager uses a separate phone as the test device.
The worksheet makes the expected result and next owner explicit. It is a review of menu presentation and scope, not a sales or payment calculation.
| Check | Expected result | Owner and next action |
|---|---|---|
| Item | Garden bowl appears with the intended lunch description in the patio preview. | Editor corrects the draft if the name or description is wrong. |
| Price | Patio view shows $14; the current dining room listing remains $12. | Shift manager checks both views and returns any mismatch to the editor. |
| Service area | The revised listing is assigned to the patio, not the dining room. | Editor verifies the assignment; manager approves the scope. |
| Approval and recovery | No publication until the manager approves. If the live result is wrong, restore the recorded prior details and check both areas. | Manager authorizes publication or recovery; editor makes the correction. |
First, the editor records the current live listing and enters the proposed change in the vendor's draft or test workflow. The manager opens the preview on the separate phone, using the same browser path a guest would use where the system permits it. The manager checks the item and price, then switches to the dining room view or uses the appropriate test link to check that it has not changed.
Next, the manager compares the screen with the worksheet. If the patio price is $12 instead of $14, or the dining room also shows $14, the result is a failure. The editor corrects the draft and the manager checks it again. Approval means the stated checks passed; it should not be inferred from someone merely opening the link.
If the system supports scheduling, the manager can approve a specific publication time after the review. Record who is responsible for confirming the live result. If the system has no private preview, ask the vendor to demonstrate another safe review method. Do not publish an unapproved change merely to create a preview.
The recovery plan should name the action as well as the owner. For this example, the editor would restore the recorded previous item details and assignments, while the manager checks the patio and dining room views again. If restoring the prior state cannot be done quickly, the manager needs an agreed manual fallback, such as removing the affected listing if the system allows it and directing guests to staff. Confirm those controls before relying on them.
Run a vendor acceptance check before purchase
Give each vendor the same short scenario and ask them to show the screens and permissions your staff would use. Use a simulated or non-transactional environment. The practice must not create a real card payment, send a guest message or dispatch a courier. A live service pilot is a separate decision: only consider one after the safe checks pass, with staff prepared to monitor and correct the public menu.
- Draft isolation: Change the test item and price. Pass if the manager can inspect the proposed result without the live guest menu changing. Fail if the only way to inspect the accurate result is to publish it.
- Scope: Assign the change to the intended service area. Pass if the manager can verify both the intended area and an area that should remain unchanged. Fail if the vendor cannot demonstrate the distinction.
- Approval: Show who can edit and who can publish. Pass if the restaurant can enforce its chosen approval process, whether through permissions or a clearly workable manual handoff. Fail if publication can occur without the required approval and the team cannot control that risk.
- Timing: If scheduling matters, set a future publication and demonstrate how to inspect, change or cancel it. Pass only if the demonstrated controls match the restaurant's needs. If scheduling is optional, record its absence as a tradeoff rather than an automatic failure.
- Exception and recovery: Simulate a wrong service-area assignment. Pass if the team can identify the error and demonstrate a correction or an acceptable manual fallback. Fail if no one can explain how to recover or verify the result.
Ask support what information they need if a published menu does not match the approved view, how to reach them during your service hours, and what your staff can do while waiting. Also ask whether a guest must refresh a page or scan again to see a correction. These answers affect how you handle a mistake at a busy table.
For an ordering setup, extend the discussion beyond the menu screen. Fleksa's QR ordering lets guests scan, order and pay at the table in a browser without an app. Ask how your proposed setup identifies the table, shows payment status to staff and handles a guest who does not want to use a phone. Review how it fits with your restaurant POS system and other restaurant management software, rather than assuming every screen shares the same menu settings.
Next step: Take the worksheet to a Fleksa discussion and ask for a demonstration of your item, price, service-area, approval and recovery requirements. Confirm which features are available for your setup before deciding.
Frequently asked questions
Does scheduling a QR menu change let me preview it?
Not necessarily. Scheduling sets a future publication time; previewing lets someone inspect a proposed view. Ask the vendor to demonstrate each capability separately, including how to cancel a scheduled change.
Who should approve a QR menu change?
Name a manager who can check the item, price, service area and timing. The editor can prepare the change, but the approver should confirm the expected guest view before authorizing publication.
What if there is no private preview?
Ask for another safe review method and determine whether it meets your approval requirements. If it does not, weigh the risk of checking only after publication against your ability to correct the menu quickly and direct guests to staff.
