A rushed cook taps Complete and sees no immediate response. The cook taps again. The buying question is simple: does that second tap affect the same ticket, do nothing, or complete the next ticket after the screen changes?
Before buying a kitchen display system, ask the vendor to demonstrate that sequence on the proposed setup. Check for a visible change in the first ticket’s state, then verify that the next ticket remains open unless a cook deliberately selects it. Also agree on how the team will find and correct an unintended completion.
The kitchen lead should define what counts as a safe result. The owner or operations manager can make it an acceptance condition in the purchase discussion, with the vendor showing how the behavior works on the intended devices and configuration.
Define the action you need to protect
Completion controls can mean different things in different kitchens. A cook may complete an item, a station’s portion of a ticket, or an entire order. Before testing, identify the exact control staff will use and what completing it tells the next person to do. Repeat the test for each completion action that matters to service.
An accidental second completion can hide work that still needs to be cooked. It can also give an expediter or another station a misleading view of progress. The problem is not limited to whether a completed ticket can later be found: first, you need to know whether the extra tap changed another ticket at all.
Ask the kitchen lead to describe the normal handoff. Who watches the screen after a cook completes an item? Who checks that the order is ready? If a ticket disappears unexpectedly, who has authority to stop the handoff and verify it? A display control is only useful if the people relying on it understand its state.
Set a clear acceptance rule: after one intended completion and an accidental repeat tap, the first ticket must show a recognizable completed state, and no other ticket may be completed by that repeat action. If the screen moves to a new ticket between taps, the demonstration needs to cover that transition explicitly.
Compare safeguards, not just screen layouts
Ask each vendor to show the same sequence rather than comparing screenshots. A large button may be easy to hit, but its size alone does not explain what happens when the ticket under it changes. Watch both the screen and the status of the tickets after each tap.
Repeated taps on the same control
Some designs may prevent an immediate repeat action or require a deliberate selection before another ticket can be completed. Others may offer a confirmation step. Ask what the proposed setup does, how long any protection lasts, and whether the behavior changes for item, station or full-ticket completion.
A confirmation step can make a consequential action clearer, but it also adds a touch during service. Have the kitchen lead judge whether the extra step is workable at the busiest station. A safeguard that staff routinely rush through is not much comfort.
Delayed response and a changing screen
Test a delayed response in a vendor-supported training environment. Ask the vendor to demonstrate how the screen behaves while an action is pending and what happens if the first ticket disappears before the second tap arrives. A spinner, status change or other visible feedback can tell a cook that the first input was received; ask whether that feedback remains clear under the conditions being demonstrated.
Do not assume a short delay test covers every network or device condition. Ask which delays the vendor can safely simulate and what behavior the restaurant should expect when a response takes longer. If the vendor cannot reproduce a particular condition, record it as an open question rather than treating it as a pass.
Recovery after an unintended completion
Ask how a manager can identify what changed, check the order details and restore or communicate the work. A system may offer a recovery control, but do not assume recall or reversal is available in the configuration you are buying. If it is not, agree on a manual method: consult the order record, tell the affected station what remains to be made, and verify the handoff with the expediter.
Recovery is a backup, not a substitute for preventing the second action. A team that must search for missing work after every uncertain tap has gained another task in the middle of service.
Use a double-tap worksheet
The following is a hypothetical training scenario, not a result from any product. Two test tickets are visible: ticket A has one burger, and ticket B has one salad. The cook intends to complete only ticket A. The kitchen lead observes; the vendor operates the training setup and explains the resulting states.
Run the exercise without real orders, payments, guest messages or courier dispatches. Ask the vendor to confirm that the training environment cannot trigger those actions before starting. Record what actually happens beside the expected result; do not mark a test as passed just because the screen looks plausible at a glance.
| Check | Expected result | Owner of next action |
|---|---|---|
| Tap Complete on A once | A visibly changes to its completed state; B remains open. | Kitchen lead verifies both ticket states. |
| Repeat the tap quickly | The repeat does not complete B, including if B moves into A’s former position. | Vendor shows B’s status; kitchen lead records pass or fail. |
| Repeat with a simulated delayed response | Pending or completed state is visible; the second tap does not complete B. | Vendor explains the simulated delay; kitchen lead verifies both states. |
| Simulate an unintended completion | The team can identify the affected work and use the agreed recovery or manual procedure. | Expediter verifies the work; manager records the exception. |
In the first row, the visible change must be understandable to the cook, not merely a status the vendor can find elsewhere. In the second, watch the exact spot where the finger lands. If ticket B replaces A under the same control and the second tap completes B, the test fails even if the first tap worked correctly.
For the delay check, note what was delayed and how the vendor produced the delay. If the screen shows no useful feedback, a cook may reasonably tap again. Treat that as a failed confirmation requirement, even if the second tap happens not to change B in that run.
For the exception, the expediter should state which dish remains to be made and how the station will be told. If a built-in recovery action is demonstrated, check the ticket state afterward. If the procedure is manual, verify that the order details are still accessible and that someone is responsible for confirming the correction. Either way, avoid declaring recovery successful until the team can account for both tickets.
Make the demonstration a purchase condition
Give the vendor the worksheet before the demo and request the proposed hardware, software configuration and completion workflow. Include the people who will actually use the screen. The kitchen lead can act as the cook while the expediter checks the downstream view. The owner records the result and any unresolved setup questions.
- Set the baseline. Confirm which test ticket is A, which is B and which completion action is being tested. Both should start open.
- Run the normal and rapid-repeat checks. Observe whether A changes visibly and whether B remains open after the second touch.
- Run the delay check. Use a vendor-supported simulation and document its limits. Watch for visible pending or completed feedback and verify B’s state.
- Run the exception. Simulate an unintended completion and have the team carry out the agreed recovery or manual handoff.
- Record the decision. Pass only if the agreed behavior and recovery steps work for the demonstrated conditions. Record a failure or an untested condition separately.
Ask support a specific question: “If a cook reports that a second tap completed another ticket, what information should we capture, and how do we get help during service?” Also ask whether the behavior depends on device, configuration or software version, and how a later update is communicated.
After a successful simulation, plan a supervised service pilot with a named person watching exceptions. That is a live service period, not a practice scenario: use your normal order controls and guest procedures. Log any ambiguous state or accidental completion and review it with the vendor before expanding use. A successful simulation reduces uncertainty; it does not guarantee that every live condition will behave the same way.
Consider the control in the wider workflow too. Your restaurant POS system and restaurant management software may be part of how staff check an order’s status. Ask the vendor to show the actual handoff for your setup rather than assuming every screen will display the same state.
Next step: Compare your KDS requirements with Fleksa. Bring the worksheet to a demonstration and confirm feature availability and the behavior of the completion controls for your setup.
Frequently asked questions
What is the most important double-tap test?
Complete one test ticket, then tap the same location again as quickly as a rushed cook might. Verify that the first action is visibly confirmed and that the second tap does not complete another ticket, including one that moves into the same position.
Is a recall function enough to handle accidental taps?
No. Recovery matters, but first establish whether a second tap can change another ticket and how staff will notice. Ask the vendor to demonstrate its available recovery method or agree on a manual procedure.
Should staff practice with live orders?
Start in a vendor-supported training environment that cannot send real payments, guest messages or courier dispatches. Once the team understands the workflow, use a separately planned, supervised live service pilot to observe real operating conditions.
