To check a restaurant kiosk menu sync delay, publish a harmless test edit, note the publish time, and check each kiosk separately until it displays the new value. Record the first time you see the change on each device—not just the time the menu editor says it was published. A kiosk checked once a minute could have updated at any point since the previous check.
Set a practical time limit with your vendor before you start. If a device still shows the old value at that limit, treat it as stale and follow an agreed fallback. One successful check shows what happened under those conditions; it does not guarantee that every future edit will travel at the same speed.
Choose a harmless edit and set the rules
Ask your vendor for a permitted test environment and test devices that represent the kiosks you intend to use. Confirm whether publishing there sends an update to those devices, whether the devices refresh automatically, and whether a screen must be reopened before a change can appear. Those details determine what your timing exercise actually measures.
Choose a visible text change that cannot affect an order. For example, change a fictional test item description from “Sample description A” to “Sample description B.” Avoid changing a live price, modifier, availability setting, or payment option just to measure sync. This check is about how quickly a published edit appears, not whether sold-out controls work.
Keep the exercise isolated from guest activity. Do not submit a real payment, send a guest message, or dispatch a courier. If the test environment allows simulated ordering, ask how to keep that activity separate too. You do not need to place an order to check whether a description appears.
Agree on a threshold before publishing. It should reflect how long your team can reasonably wait before acting, not an assumed vendor guarantee. Also agree on the polling interval, the clock to use, who will check each screen, and what happens if a device is offline. A shared clock or synchronized device clocks make the log easier to interpret.
Before you begin, ask the vendor:
- What action counts as publication, and where can staff see that it completed?
- Should the edit reach every kiosk automatically, or does a device need a refresh or another action?
- Can staff see a menu version or last-update time on each device? If not, what displayed value should they check?
- Which network and device conditions are required for the change to arrive?
Record the starting value on every device
Give each kiosk a stable name, such as K1, K2, and K3, and note its location. A label on the device and a matching entry in the log help the person checking it avoid recording the same screen twice. If the vendor exposes a reliable menu version, record it. If not, record the exact visible description before and after the edit.
Open the same item view on each device before publishing. Note whether the old description is visible and whether the kiosk appears connected. If a screen is asleep, on a different menu, or unable to load the item, write that down instead of treating it as a normal starting point. Resolve the issue or keep the device's result separate.
Record the publish time when the system indicates that the edit has been published. If the system distinguishes between submitting an edit and completing publication, capture both times. For the comparison below, the starting time is completed publication. The person checking should not manually refresh some devices and leave others untouched unless the log identifies those actions; otherwise the results are hard to compare.
The kiosk documentation can help you prepare questions about the workflow. For your own setup, confirm the steps with the vendor rather than assuming every screen and version behaves alike. If menus also appear through a restaurant POS system, ask whether publishing there is the same event as publishing to kiosks.
Log what each kiosk shows after publication
Hypothetical example: A restaurant has three test kiosks. Staff publish the description change at 2:00 p.m., check each device once per minute, and agree to flag any device that has not shown the new description by 2:03 p.m. The team checks the same item view without manually refreshing it.
| Device | Before publication | First observed new value | Decision at 2:03 |
|---|---|---|---|
| K1 | Sample description A | 2:01 p.m. | Within threshold |
| K2 | Sample description A | 2:02 p.m. | Within threshold |
| K3 | Sample description A | 2:06 p.m. | Stale; escalate |
The table records the first observation, not an exact arrival time. K2 still showed the old text at 2:01 and showed the new text at 2:02, so its update appeared sometime in that one-minute window. K3 still showed the old text at the 2:03 threshold and was flagged then. Its later update did not erase that missed threshold.
On these assumptions, K1 and K2 met the team's chosen limit during this run; K3 did not. The next action is to investigate K3 before relying on that device for time-sensitive changes. This result does not establish a typical delay for the system, prove why K3 lagged, or predict how a price change would behave.
Keep the full notes with the summary: each check time, the value observed, any connection warning, and any action taken on the screen. If a device was not checked on schedule, record the gap. A delayed observation may reflect a missed check rather than a delayed update.
Repeat the exercise if the first run had an interruption or if you need to compare different conditions. Change one condition at a time where practical. For example, check whether opening the item again makes a difference, then label that as a separate run. Do not combine automatic and manually refreshed results into one claimed sync time.
Set a fallback and an escalation point
Before a live service pilot, decide who can take a stale kiosk out of guest use, how staff will recognize it, and where a guest should go instead. A simple fallback may be to cover or clearly mark the affected screen and direct the guest to a staffed order point. Make sure the staffed point has the correct information before using it as the alternative.
Do not assume that a menu edit has reached another ordering channel just because it reached one kiosk. Ask the vendor how to verify each channel you plan to use as a fallback. If the edit concerns an important live price or item detail, staff should use the restaurant's approved process for resolving the discrepancy rather than asking a guest to guess which display is right.
For a simulated check, practice identifying the stale device and recording the escalation without contacting a guest or creating an order. A live service pilot is a separate decision: agree on its scope, staffing, fallback, and stop conditions first. The simulation provides useful preparation, but it cannot establish how guests or staff will respond during service.
When the threshold is missed, send support a compact record: device identifier, test environment, published value, publication time, each relevant observation time, connection status, and any refresh or restart. Ask what evidence would help distinguish a publishing issue from a device or network issue. Also ask who owns the next action and when staff should expect an update.
Do not repeatedly restart a device during the timed run unless that is the agreed procedure. A restart can be a useful recovery step, but it changes the conditions and should be logged separately. After a fix, run another isolated check rather than assuming the original problem is resolved.
Use the result in your buying decision
Ask each vendor to demonstrate the same basic workflow: make a harmless edit, publish it, and show how staff can tell what each device displays. Compare the visibility of the process as well as the observed timing. A fast update is less useful operationally if the team cannot identify a stale device or has no workable fallback.
Include device setup, installation, support, and payment compatibility in the wider purchase conversation. A kiosk break-even guide can help frame those costs separately from the sync check. Do not treat a menu timing exercise as proof of payment behavior, kitchen throughput, or total operating cost.
As a next step, take your proposed test edit, device list, threshold, and fallback to Fleksa. Review the restaurant kiosk workflow and ask Fleksa to confirm the relevant setup and current availability for your location.
Frequently asked questions
Is the first observed update the exact sync time?
No. It is the first time your checker saw the new value. The actual change may have appeared at any point after the previous check, so record the polling interval as well.
Should I test a real price change?
Use a harmless text edit in a permitted test environment for the timing check. If price behavior also matters, agree on a separate, controlled demonstration with the vendor before changing a live menu.
What should I do if one kiosk stays stale?
Flag it at the agreed threshold, follow the device fallback, and give support the device-by-device log. Record any recovery action separately, then repeat the isolated check after the issue is addressed.
