To verify KDS order status synchronization, follow one identifiable practice order through every screen that should receive it. Record what each station does, what expo should see after each action, and whether the screens converge within the update time the vendor commits to. A matching ticket number alone is not enough: the item and completion states must agree too.
Start by agreeing on the expected workflow with the vendor. Some kitchens need each station to complete its own items before expo sees the whole ticket as ready. Screen labels and actions can differ, so write down the expected behavior for the setup you are considering rather than assuming every KDS works the same way.
Map the order, stations, and completion events
Choose an order that crosses at least two preparation areas. Give it a distinctive ticket identifier and make the items easy to recognize. Include a modifier if modifiers matter to your operation: staff need to know they are comparing the same item, not just two tickets with the same table or pickup name.
For the hypothetical example below, ticket K-42 contains one burger with no onion and one side salad. The burger goes to Grill, the salad goes to Cold, and expo needs to see the progress of both. The proposed workflow is that each station marks its own item complete; expo shows the whole ticket as ready only after both items are complete. These are assumptions for the example, not claims about a particular product.
Before starting, ask the vendor to describe what should appear on each screen when the order arrives and after each station acts. A station may show only its assigned item, while expo may show the full ticket. The screens do not have to look identical to agree. They need to represent the same underlying progress in a way your team can interpret.
Write down the exact action that counts as station completion. Is it a tap on an item, a ticket-level action, or another step? Ask whether expo can change station progress and what should happen if someone makes a mistake. Do not build a training plan around recall or reversal until the vendor demonstrates the available correction workflow.
The guide to routing kitchen tickets by preparation station can help you decide which items belong on which screen. For this check, keep the routing fixed so you can focus on status changes rather than troubleshooting a menu setup at the same time.
Follow one ticket across all three screens
The table shows the expected sequence for K-42 under the agreed hypothetical workflow. “Complete” refers to the station's preparation action. “Whole ticket ready” is the example's expo state, reached only after both station actions. It does not establish that food was handed to a guest or driver.
| Event | Grill screen | Cold screen | Expo screen |
|---|---|---|---|
| Order arrives | K-42 burger with no onion: open | K-42 side salad: open | K-42 shows both items open |
| Grill completes burger | Burger: complete | Salad: open | Burger complete; salad open; whole ticket not ready |
| Cold completes salad | Burger: complete | Salad: complete | Both items complete; whole ticket ready |
The exact labels, and whether a completed item stays visible on a station screen, may differ. If a screen removes completed items, ask the vendor how staff can verify the action and what expo should show in its place. Adapt the expected-state record before the demonstration; do not count a disappearing item as either a pass or a failure without knowing what it means.
Run the sequence in a vendor-supported training environment. Have one person operate Grill, another operate Cold, and a third watch expo. Use a fictitious order and confirm that the simulation cannot trigger a real payment, guest message, or courier dispatch. Record each action and the time it was made, then record when the corresponding change appears on each relevant screen.
Watch the intermediate state, not just the final one. If expo shows the whole ticket ready after Grill finishes but before Cold acts, the screens do not meet the example's agreed expectation. If expo still shows the burger open after Grill completes it, note how long the discrepancy lasts and whether it resolves within the vendor's stated update window.
Repeat the sequence with Cold finishing first. That checks whether the outcome depends on the order in which staff work. Then ask to see the same process using a modifier and order type your kitchen commonly handles. Fleksa's kitchen display documentation is a starting point for discussing its display workflow; confirm the behavior of the configuration you would actually use.
Simulate a delay and set an escalation rule
A normal sequence shows what happens when screens are updating as expected. A delayed-update drill asks a different question: can staff spot disagreement and respond without guessing which screen is right?
First, ask the vendor for a safe, supported way to simulate a delayed or interrupted update in the training environment. Do not disconnect production equipment during service or invent a failure method that could affect live orders. If the vendor cannot safely reproduce a delay, use a tabletop drill instead: describe the mismatch and have staff explain what they would do. That checks the response plan, not the software's recovery behavior.
In the drill, suppose Grill has completed the burger but expo still shows it open. The expo operator should identify K-42 and the affected item, check with Grill, and follow the restaurant's agreed procedure rather than silently completing the order based on an assumption. Assign one person to coordinate the discrepancy so multiple staff do not make conflicting changes.
Agree on an escalation point using the vendor's update commitment and the pace of your service. For example, staff might first confirm the action at the station, then notify the shift lead if the display remains inconsistent beyond the agreed window. The lead needs a practical fallback for communicating the order's status and a way to contact support if the issue persists.
Ask the vendor what happens when updates resume: which screen should reflect the final state, how staff can confirm it, and whether any manual correction is required. Do not assume an interrupted screen automatically catches up or that every action can be undone. Record both the recovery steps and the person responsible for checking them.
After simulated training, a supervised service period is a separate step. Use real operating procedures, watch for discrepancies, and give the shift lead authority to use the agreed fallback. A smooth practice run reduces uncertainty, but it cannot prove that every busy-service condition will behave the same way.
Compare the result with the vendor's commitment
Give each vendor the same order, station map, action sequence, and observation sheet. Ask for the expected screen states and update window in writing before the demonstration. That makes it easier to separate a configuration difference from a missed commitment.
For each event, record the action, expected result, observed result, and time to appear. Also record who must act when the screens disagree. A vendor may show a quick update during a demonstration but still leave an important operational question unanswered, such as how a shift lead identifies the authoritative state after a screen reconnects.
For the hypothetical K-42 workflow, a reasonable decision rule is to advance a setup for further consideration if both completion sequences produce the agreed intermediate and final states within the stated window, and staff can explain the escalation procedure. If expo marks the whole ticket ready while one item remains open, or if the vendor cannot explain how to resolve a persistent mismatch, pause the decision and request a corrected setup or a clear answer.
That decision has limits. One order does not establish performance under a full rush, after every network interruption, or with every menu item. Ask for additional demonstrations using your busiest routing patterns and any correction scenarios that matter to your team. Also ask what devices, setup work, support, and additional screens are included in the written quote. Compare quoted operating totals on the same scope rather than assuming screen costs are included.
Square describes station routing and expeditor functions in its KDS. Toast offers a kitchen display product. Fleksa offers a kitchen display linked to restaurant orders. For each option, ask the vendor to demonstrate the specific station-to-expo status workflow, device requirements, interruption behavior, and screen charges for your setup.
Next, take your station map and the K-42-style sequence to a Fleksa kitchen display system discussion. Compare the relevant workflow and current availability with Fleksa, and ask for the expected screen states and support process in writing.
Frequently asked questions
Do station and expo screens need to look identical?
No. A station may show only its assigned items while expo sees the whole order. They should still convey consistent progress according to the workflow you agreed with the vendor.
How long should a status update take?
Ask the vendor for a commitment relevant to your configuration and record actual observation times during the demonstration. Use that commitment to set a staff escalation point.
Does a completed KDS ticket mean the guest received the order?
Not necessarily. A preparation completion state and a handoff are different events. Ask how your intended workflow records or communicates each one before training staff.
