To detect kitchen display ticket overflow, compare the tickets visible on the screen with the full active queue, then check which tickets are outside the current view. Do this on the display and layout your kitchen actually uses, with long as well as short orders. Assign one person to make the comparison during service and another to respond when the queue crosses a set threshold.
A screen filled with tickets does not tell you how many more are waiting. It also does not tell you whether an older order has slipped out of view. The buying question is whether staff can find that difference quickly enough to act, without losing their place in the queue.
Compare the screen with the full active queue
Start by agreeing on what counts as an active ticket: an order that has reached the kitchen and still needs work under your service procedure. Exclude completed tickets from the comparison. Decide how you will treat held future orders, since those should not be mistaken for orders ready to prepare.
Ask the vendor to show where the full active queue can be viewed or counted for the station being tested. It might be available on the display itself or through another view. Confirm that both views cover the same station, order types and ticket status. If there is no reliable way to compare them, finding overflow becomes a manual task rather than a dependable screen check.
Hypothetical example: A kitchen has one display at its grill station. With short tickets at the chosen text size, six tickets fit in the visible area. Nine active grill tickets are waiting, ordered oldest first. The table shows the expected view before anyone scrolls.
| Queue position | Ticket | Visible initially? | Action |
|---|---|---|---|
| 1–3 | A–C, older tickets | Yes | Continue preparation; watch ticket age |
| 4–6 | D–F | Yes | Keep in the active queue |
| 7–9 | G–I | No | Queue checker finds them by scrolling or another supported view |
Here, nine active tickets minus six visible tickets means three are outside the initial view. That is a count of tickets, not menu items or portions. The table assumes short tickets and oldest-first ordering; neither assumption should be carried into a real service without checking the actual configuration.
Ask the vendor what happens when new tickets arrive: are they added at one end, can the screen move automatically, and is there an indicator that more tickets exist? Also ask whether a ticket can disappear from the current view when another ticket grows. A visible overflow indicator is helpful only if staff can recognize it and reach the hidden tickets quickly.
Test long tickets and scrolling on the working display
A capacity estimate based on six short tickets can fail when orders contain modifiers or many lines. Use a vendor-supported training environment to build a queue resembling your menu: a few short orders, a long order with modifiers, and a mix of order types your station normally receives. Use the intended monitor, orientation, text size and viewing distance.
In the example above, suppose a long ticket takes enough room that only four of the same nine active tickets are visible at once. Five are now outside the initial view. That does not mean five orders are late, but it does mean a worker looking only at the first screen cannot account for the whole queue.
Run the check as a simulation. Training entries must not cause a real card payment, guest message or courier dispatch. Confirm those safeguards with the vendor before entering the practice orders. Do not treat a simulated result as proof of how every live integration will behave.
- Record the active ticket IDs and their order in the training queue. Note the number visible before touching the screen.
- Find each off-screen ticket using the controls offered. Check whether its item names, quantities and modifiers remain readable.
- Return to the original view. Check whether the display makes it obvious where the worker is in the queue.
- Add a simulated ticket while the worker is viewing another part of the queue. Check how the arrival is signaled and whether the view changes.
- Repeat with the longest realistic ticket and with the screen settings the kitchen intends to use.
Time the check if speed matters to your decision, but also watch for missed IDs and confusing controls. A fast scroll that skips a ticket is not a passing result. Ask what happens if someone completes a ticket while another worker is viewing the queue, and whether a mistaken completion can be recovered. Do not assume every system supports recall.
Fleksa describes its kitchen display system as showing order type, items, quantities and modifiers, with configurable timing and color indications. Ask to see the overflow and scrolling behavior for your intended setup rather than assuming those details work a particular way. Its kitchen display documentation is a useful starting point for that conversation.
Give one worker ownership of the off-screen check
The screen can make an overflow visible, but someone still needs to look. During a rush, assign a queue checker for each relevant station or display. That person compares the active queue with the visible tickets, checks the oldest off-screen work and tells the shift lead when the agreed threshold is reached. Name a backup before service so the check does not stop when the assigned worker takes a break or moves to another task.
The shift lead owns the response, not just the notification. Depending on your kitchen, that could mean moving a worker to the station, pausing an internal task or coordinating with the front counter about wait times. Agree on actions the lead can actually take. Do not build the plan around rerouting tickets unless the vendor has demonstrated that workflow for your setup.
Use ticket IDs and ages when handing off. “There are three more tickets” is less useful than identifying the oldest unseen ticket and saying how long it has waited. Define whether age begins when the order is placed, accepted or sent to the station, and use the same starting point in the test and the service procedure.
Decide how often the checker looks. A short recurring check may suit a station with frequent orders; a quieter station may need a different interval. The important point is that checking must fit around preparation without requiring a cook to abandon a critical task. If nobody can perform it consistently, the workflow needs another control or a different staffing plan.
Station routing affects what the checker sees. Review your intended assignments with the vendor and use the guide to routing kitchen tickets by preparation station to frame the questions. The queue count and the screen being checked must refer to the same work; comparing a whole-restaurant count with one station’s display can create a false alarm.
Set an escalation threshold and repeat the check
For the hypothetical grill station, the owner might choose to alert the shift lead when the active queue reaches seven tickets or when any active ticket has waited eight minutes. Seven is one above the six-short-ticket screen capacity; the time limit provides a separate warning for an old order even when the queue is smaller. These are trial thresholds, not recommended service times for every restaurant.
Under those assumptions, nine active tickets trigger escalation on count alone. The queue checker reports the total and identifies the oldest off-screen ticket; the shift lead decides whether to add help or take another agreed action. With the long-ticket layout, overflow starts sooner, so the owner should consider lowering the count threshold or choosing a more reliable indicator if the display exposes one.
The example does not establish whether a real vendor can show a full count, sort by age or alert staff automatically. If the demonstration cannot provide a dependable count or a quick way to find older tickets, choose a documented manual check or keep evaluating other workflows. If the check itself takes too long for the staffing available, a threshold alone will not solve the problem.
After the simulation, run a separate supervised service pilot with the normal live-order safeguards and the named checker and lead in place. Observe whether the checks happen at the planned interval, whether alerts reach the lead and whether the response is workable. Record missed checks and confusing handoffs without treating the pilot as a guarantee that every future ticket will be seen.
Adjust the threshold and repeat the simulation when you change the screen size, text settings, station assignment or menu layout. Ask for a written quote for the proposed setup, including any additional displays or services, before comparing operating costs.
For a next step, bring your longest realistic ticket and intended station layout to a demonstration. Compare the KDS workflow and current availability with Fleksa, including how your team would count, find and escalate off-screen tickets.
Frequently asked questions
Does a full KDS screen mean tickets are hidden?
Not necessarily. Compare the visible tickets with the full active queue for the same station. If the active count is higher, find the remaining tickets using the supported view or controls.
Can long orders reduce the number of visible tickets?
They can if the display gives longer tickets more vertical or horizontal space. Test realistic modifiers and quantities on the intended screen and text settings.
Who should check for off-screen orders?
Assign a named queue checker and a backup for each relevant station. The shift lead should own the response when the checker reports an order or queue beyond the agreed threshold.
