To identify conflicting QR menu versions, compare the published source menu with two guest views: a fresh scan and a page that was open before the change. Record the same item, price, availability, and publication time for each. If either device shows something different from the current source, you have found a conflict that needs an explanation and a staff response.
The important distinction is between what staff can see and what they assume. A menu that looks correct on the manager’s phone does not prove that a guest’s older page has updated. This test focuses on what devices display after publication, rather than on what happens to an open cart during a change.
Start with one published menu change
Choose a change that is easy to recognize and safe to demonstrate. A temporary name or price on a demonstration menu works better than a subtle description edit. Ask the vendor to use a test environment or another controlled setup where the change will not mislead actual guests. Keep real ordering and payment out of the exercise.
Before changing anything, have the manager record the item as it appears in the menu editor. Capture its name, price, availability, and any version identifier the system provides. If there is no visible version identifier, use your own labels, such as “before change” and “after change.” Those labels are staff notes, not proof that the software tracks versions.
Publish the change and record the time shown by the system, if available. If it does not show a publication time, note the time the operator completed the publish action and label it as an observation. Then reopen or refresh the source menu as appropriate and confirm what the system now presents as published. The source is your reference point for the device comparison; a draft sitting in an editor is not enough.
Also write down the inputs that could affect the result: which QR code was scanned, which menu or location it leads to, the device and browser, and whether the page was already open. Use the same code and menu for both devices. If the vendor offers location-specific menus, confirm that both views are intended for the same location. Otherwise, a difference between menus could be mistaken for a stale version.
For a broader decision about where QR ordering belongs in service, see the guide to QR ordering in table service. For this test, keep the question narrower: does each guest view match the menu that staff believe is published?
Compare a fresh scan with an open page
Use two devices if possible. On the first, open the QR menu before the change and leave the page open. On the second, wait until after publication, then scan the same code in a new browser session. Observe both screens without refreshing the first one. Next, refresh the already-open page and record what happens. Keep these observations separate: an automatic update and an update after refresh are different results.
The following worksheet is a hypothetical example, not a product test. Assume a demonstration menu has one location and one QR code. Before publication, the soup is $8 and available. The manager changes it to $9 and publishes it at 2:15 p.m.; availability stays the same. The published source then shows $9. The table compares two possible device outcomes against that source.
| Check | Reference or expected result | Outcome A | Outcome B |
|---|---|---|---|
| Published source after 2:15 p.m. | Soup, $9, available | $9, available | $9, available |
| Fresh scan after publication | Match published source | $9, available | $8, available |
| Previously open page, before refresh | Record what the guest sees | $8, available | $8, available |
| Previously open page, after refresh | Match published source | $9, available | $8, available |
| Decision | Use the acceptance criteria agreed before the demo | Pass only if a refresh is acceptable and the guest has a clear prompt or staff can reliably direct one | Fail: both guest views still conflict with the source |
Outcome A reveals a limited but manageable difference only if the restaurant accepts refresh as part of its workflow. If the requirement is that an already-open page must update automatically, Outcome A fails that requirement. Outcome B is more serious for this decision: even a new scan does not show the published price, and refreshing the older page does not fix it. Do not choose between products on the label “live menu” alone; ask the vendor to demonstrate the behavior your team actually requires.
Repeat the comparison with an availability change if sold-out items are a major concern. A price update and an unavailable item can affect service differently. Define the expected behavior before the demonstration, including whether an unavailable item should disappear or remain visible with a clear status.
Investigate a mismatch without misleading guests
The shift manager should own the first check. When a server or guest reports a different price or item status, the manager compares the guest view with the published source and notes the time, device, browser, menu location, and whether the page was opened before the change. A screenshot can help preserve what was visible before anyone refreshes, provided the team follows its normal privacy practices and avoids capturing unnecessary guest information.
A previously loaded page may be showing cached content, but do not assume caching is the cause. First check for a different QR code, location, menu, or unpublished edit. Then try a refresh and a fresh scan as separate checks. Ask the vendor what the expected update behavior is and how staff can tell whether a device has received the current menu. A visible timestamp or version marker can help if the product provides one; if it does not, ask what other reliable signal staff should use.
Prevent a misleading result by keeping the original observation separate from the retest. If someone refreshes immediately and the page changes, recording only the final screen hides the fact that the guest initially saw an older price. Likewise, a fresh scan that works on the manager’s phone does not establish what happened on the guest’s already-open page.
During actual service, staff should not guess which screen is current. The manager should confirm the published item and give the guest the correct information through the restaurant’s normal service process. If the mismatch persists, pause use of the affected QR menu or direct guests to an approved alternative until the manager can confirm what is current. Keep a non-phone option available so a device issue does not leave a guest unable to see the menu.
The restaurant POS system may also show item information, but do not assume it is the same publication source as the QR page. Ask where the authoritative menu is maintained, how changes reach each guest view, and who can check the result. If staff use broader restaurant management software, establish who owns the menu record and who is allowed to publish changes.
Set a pass condition before the vendor demo
Write the acceptance rule around your service model. A counter-service restaurant that changes availability frequently may require a different response from a dining room that updates prices outside service. The rule should cover the fresh scan, the previously open page, and the action staff take when either one disagrees with the source.
- Set up safely. Ask the vendor to demonstrate on a test menu or controlled setup. The exercise must not create a real payment, guest message, or courier dispatch. Use display-only checks or a simulation for any later workflow steps.
- Record the baseline. The manager notes the item, price, availability, QR destination, device details, and the source used for the comparison. Leave one page open before publishing.
- Publish and observe. Record the publication time or the observed publish time. Confirm the new values in the published source, then scan on a second device. Record the open page before and after refresh.
- Compare against the agreed rule. A pass requires the fresh scan to match the published source and the open page to meet the restaurant’s stated update requirement. If refresh is permitted, it must produce the current values and the team must have a clear way to prompt or direct it. Any unresolved mismatch is a fail for that requirement.
- Assign the exception. The shift manager records the conflict and contacts the vendor’s support channel if the normal refresh or rescan step does not resolve it. Ask for an escalation contact, the information support needs, and the expected response process before signing.
This is a simulated demonstration, not a live service pilot. If it passes, the restaurant can plan a separate, controlled live pilot with staff responsibilities and a fallback agreed in advance. Do not assume a passing demonstration guarantees that every guest device will behave identically. During the pilot, staff should watch for reported mismatches and escalate them using the same owner and comparison method.
Before choosing a workflow, compare your QR requirements with Fleksa and ask for a demonstration of the current version-update behavior. Fleksa’s QR ordering lets guests scan, order, and pay at the table in a browser; confirm the specific menu-update and staff-visibility features your restaurant needs.
Frequently asked questions
Does a fresh scan prove every guest sees the current menu?
No. It shows what that device and browser received at that moment. A page opened before publication may still display different information, so check both views.
What should staff do when a guest reports an old price?
Have the shift manager compare the guest view with the published source, record the difference, and give the guest the confirmed information. If the mismatch persists, use an approved alternative and escalate it.
Should an open QR menu update automatically?
That depends on the restaurant’s requirement and the product’s behavior. Decide whether a refresh is acceptable, then ask the vendor to demonstrate the agreed behavior before purchase.
