Staff can trust ticket timing after a device clock change only if the system’s timing method and recovery have been verified. A screen showing the right current time after synchronization is a good start, but it does not prove that existing tickets have the right ages. Ask the vendor to show where ticket times come from, how the display calculates age, and what happens to tickets already on screen when the clock is corrected.
A clock error is different from a delayed completion timestamp. Here the question is whether the device’s incorrect time changes the age or timing indication staff see while preparing an order. The answer can affect which ticket the kitchen treats as urgent.
Use a vendor-supported training environment for the checks below. Simulated orders must not charge a card, message a guest, or dispatch a courier. Once the workflow is understood, a separate, supervised live service pilot can help staff assess it under normal operating conditions.
Record a baseline before changing the clock
Start with the workflow you intend to buy, not an abstract feature list. Identify the order entry point, the kitchen screen, and the timing indication cooks will use. If an expediter or another station also sees the ticket, include that view in the demonstration. The guide to routing kitchen tickets by preparation station can help you identify which screens need to be observed.
Ask the vendor which event starts the timer. Is it order creation, acceptance, transmission to the kitchen, or another event? A ticket can have several legitimate timestamps. Comparing its age against the wrong one can make a correct display look wrong, or hide a real problem.
For each practice ticket, record its identifier, the start event and its time, the screen’s displayed age, and the observation time. Also record the device’s displayed clock and time zone. Keep the time source used to judge elapsed time independent of the kitchen device. For example, use a separate synchronized reference clock and note its time at each observation.
Agree on the authoritative event record with the vendor before starting. Ask how its time is generated, whether it is affected by the kitchen device’s clock, and how the event can be retrieved later. A receipt printed by the same incorrectly timed device may not be an independent reference.
Capture the ordinary state first: create a simulated ticket, wait a known interval, and compare the displayed age with the elapsed time from the agreed start event. Note whether the screen shows seconds, rounds to minutes, or uses colors rather than an exact age. Those presentation choices matter when setting a fair tolerance.
Compare ticket age with the event record
The following is a hypothetical worksheet, not a claim about any product. The owner has agreed that a ticket’s age starts at the recorded kitchen-acceptance event. The reference clock and event record are independent of the kitchen device. The device clock is then set five minutes ahead in a vendor-supported simulation.
| Observation | Reference and device time | Expected age | Decision check |
|---|---|---|---|
| Ticket accepted | Reference 12:00; device 12:00 | 0 minutes | Save the event and ticket ID. |
| Baseline check | Reference 12:03; device 12:03 | 3 minutes | Record the displayed age and any color. |
| Clock moved ahead | Reference 12:04; device 12:09 | 4 minutes | Check whether the age stays near 4 minutes or jumps. |
| Clock synchronized | Reference 12:06; device 12:06 | 6 minutes | Check the existing ticket again and record its recovery. |
The table separates the device’s clock from elapsed time. At the third observation, the device reads 12:09, but only four minutes have passed since acceptance at 12:00. A display age near nine minutes would not meet this example’s expected result. At synchronization, the expected age is six minutes; simply seeing 12:06 on the device is not enough to establish that the ticket recovered.
Record what the display actually shows at every step. Do not assume a wrong clock will necessarily produce a wrong age: a system may calculate timing using a different source. Conversely, an age that looks reasonable at one moment may still jump or stop updating later. Check both the number and any urgency indication that staff use to prioritize work.
Repeat the comparison with a new simulated ticket created while the device clock is wrong. That separates the behavior of an existing ticket from the behavior of one received during the error. If multiple screens show the same ticket, compare each against the same start event and reference clock.
Set recovery criteria before the demonstration
Write down what your kitchen needs before seeing the result. A useful acceptance criterion names the ticket, the expected behavior, the permitted difference and the point at which staff may rely on the display again. Avoid a vague requirement such as “the clock fixes itself.”
For the hypothetical worksheet above, an owner might choose these criteria:
- The displayed age must remain within one minute of elapsed time from kitchen acceptance, allowing for a display that rounds to whole minutes.
- An existing ticket and a ticket created during the clock error must each meet that tolerance after synchronization.
- The vendor must show when staff can rely on the age again and what they should do if the display remains outside tolerance.
- Any timing color used for prioritization must be consistent with the configured threshold and the ticket’s verified age.
That one-minute tolerance is an example, not a universal rule. A busy kitchen with a short preparation window may need a tighter one; a screen that only displays whole minutes may not support it. Choose a tolerance that matches the display’s resolution and the decisions cooks actually make.
Ask the vendor to demonstrate synchronization using its supported procedure. Observe whether the existing ticket age changes immediately, needs a refresh, or requires another action. Then watch it for a further interval against the independent reference. A correct reading at the instant of synchronization does not show whether the timer continues correctly.
Also ask what happens if the device clock is behind rather than ahead, or if synchronization is unavailable. These are separate cases; do not assume the outcome will match the first simulation. If a required case cannot be demonstrated, record it as an open buying question rather than treating it as a pass.
For a supervised live service pilot, agree on a safe fallback with the manager before service. Staff might use an independently recorded order time while the issue is investigated, depending on the restaurant’s workflow. Do not deliberately change a production device’s clock during service just to repeat the simulation.
Save evidence before resetting the device
A reset may make a screen usable again, but it can also make the original problem harder to reconstruct. Before taking that step, ask support what to preserve and whether the device needs to remain in its current state. Follow the vendor’s safe handling instructions, especially if the kitchen is actively using the screen.
Send a compact incident record rather than a description such as “the timer was wrong.” Include:
- The affected device and screen, software version if available, time zone, and whether other screens showed the same ticket.
- Ticket IDs, the agreed timer start event, its authoritative timestamp, and the source of that record.
- The reference time, device clock, displayed ticket age and timing color at each observation, including before and after synchronization.
- How the clock was changed or corrected, any refresh or restart performed, and the order in which those actions occurred.
- Images or logs the vendor requests, handled according to your restaurant’s privacy practices.
Ask support to explain which clock or service supplies the timer, whether the event record can be exported, and how to tell when an affected ticket is trustworthy again. If support recommends a reset, ask what evidence to capture first and what staff should use as a timing reference until the display is verified.
Keep the outcome alongside your acceptance criteria: pass, fail, or still open, with the observations that support it. If the timing behavior is essential to your kitchen and remains open, do not treat the demonstration as a pass. Request a supported follow-up or choose a workflow that does not depend on that unverified timing indication.
Use the worksheet in a buying decision
Review the whole order path as well as the kitchen screen. Your restaurant POS system and restaurant management software may be part of the workflow being demonstrated, but the relevant event and timing behavior should be confirmed for your setup.
Fleksa’s kitchen display system shows order details including item names, quantities and modifiers, and offers configurable timing and color indications. Use the worksheet to compare your requirements with Fleksa, and ask for a demonstration of clock-error recovery in the workflow you plan to buy.
Frequently asked questions
Does correcting the device clock correct every ticket age?
Not necessarily. Check tickets that were already on screen and tickets created during the error against an independent event record. Ask the vendor when the displayed ages can be trusted again.
What if the ticket age is right but the timing color is wrong?
Record both observations. Compare the color with the configured threshold and verified ticket age, then ask the vendor to explain the mismatch before staff rely on the color for priority.
Should staff restart the screen immediately?
Follow the vendor’s support procedure. When safe, capture the ticket IDs, clock readings, displayed ages and requested logs first, because a restart may make the issue harder to investigate.
