Choose due-time sorting when orders arrive with meaningfully different promised times and the kitchen needs to see the nearest deadline first. Arrival-order sorting can work when most orders are expected at roughly the same time and prep times are similar. Neither sort alone tells a cook exactly when to start a long-prep item.
The buying question is not just which order appears at the top of a screen. It is whether the queue helps the team start the right work soon enough, without making an order far ahead of its promised time. Use the same set of tickets to compare defaults before choosing a kitchen display system.
Model three orders with different promised times
Consider this hypothetical example at noon. All three tickets are ready to cook. One cook handles one ticket at a time, with no parallel work. The prep estimates include the work needed to finish each ticket, but not extra handoff or packing time. Treat the due time as the time the food must be ready, not the time a driver or guest arrives.
| Order | Arrived | Due | Prep time |
|---|---|---|---|
| A | 11:50 a.m. | 12:40 p.m. | 12 minutes |
| B | 11:55 a.m. | 12:18 p.m. | 6 minutes |
| C | 12:00 p.m. | 12:30 p.m. | 16 minutes |
The table gives you the inputs for a shared vendor demonstration. Order A arrived first but has the latest promise. B is due first and takes the least time. C is due second and takes the longest. The three tickets need 34 minutes of cook time altogether.
Before using real tickets for a comparison, agree on what the due time means in your operation. A pickup promise may need a packing allowance; a delivery promise may need food ready before the courier is expected. If the screen sorts by a customer-facing time rather than a kitchen-ready time, ask how that difference is handled. A precise-looking clock is not useful if everyone interprets it differently.
Also decide which tickets belong in the active queue. A future order placed well before lunch should not necessarily occupy the same working position as an order needed now. Ask how held orders enter the active view and whether staff can see their timing before they are released. Fleksa's KDS page describes future held orders and configurable timing and color indications; confirm the behavior you need in your setup.
Compare arrival order with due-time order
Under first-in-first-out, or FIFO, the cook starts A at noon and finishes at 12:12. B finishes at 12:18, exactly on its due time. C finishes at 12:34, four minutes late. The sequence is easy to explain: the oldest ticket goes first. But the oldest ticket did not have the earliest promise.
Under due-time sorting, the sequence is B, C, then A. B finishes at 12:06, C at 12:22 and A at 12:34. All three finish by their stated due times under the example's assumptions. B and C are ready 12 and eight minutes early, respectively, so the operator must also decide whether those waiting times are acceptable for the food.
That result favors due-time sorting for this particular workload. It does not prove that every ticket should be cooked as soon as it reaches the top. A kitchen that prepares fragile items too early may meet the clock but hand over poor-quality food. Ask whether the display can show a useful preparation or release time, and how staff should act when the next due ticket should not be started yet.
FIFO deserves a look when walk-in tickets have similar promises and take similar amounts of time. It gives the team a predictable order and reduces arguments about whose ticket came first. Its weakness appears when a scheduled order arrives early or an immediate order enters behind tickets with later promises.
Due-time sorting is a stronger starting point when pickup, delivery and dine-in tickets carry different ready-by times. Its weakness is bad input: an unrealistic promise or an incorrect time can move a ticket into the wrong position. In a demo, change the promised time on a practice ticket and ask when and how the queue updates. Check whether the time is visible enough for a cook to understand the new position.
Check long-prep work and station capacity
Order C exposes a limit of both simple sorts. Its 16-minute prep time matters as much as its place in the queue. If the cook starts C first, it finishes at 12:16; B then finishes at 12:22, four minutes late, and A finishes at 12:34. Starting the longest item first does not beat the B-C-A sequence in this example.
That calculation depends on having one cook and no overlap. A real kitchen may start a roast while another person prepares a salad, or it may have one fryer shared by several tickets. A single overall ticket order may not describe the work available at each station. Map the bottleneck first: who can work in parallel, which equipment is shared, and where a finished component waits for the rest of the order.
For a practical check, run the same three tickets again using your actual station arrangement and realistic prep estimates. Write down each start and finish time instead of assuming that a screen sort will schedule every component. If items must go to separate screens, ask how the system routes them and how the expeditor sees an order that is partly complete. The guide to routing tickets by preparation station can help you frame that part of the demonstration.
Ask the vendor what staff can see about modifiers, quantities and order type while deciding what to start. A short ticket with a special preparation instruction may require more attention than its item count suggests. Fleksa's KDS page describes displaying those details; check their layout and readability on the screen you intend to use.
Set an override and audit the result
A default sort should cover ordinary work. It should not prevent a lead from responding when a fryer goes down, an order needs a remake or a promised time changes. Decide who can authorize a change and how the rest of the team will hear about it. Ask each vendor what staff can change on screen and what steps are needed to restore the normal queue. Do not assume a ticket can be recalled or rerouted without seeing the workflow.
Use this acceptance test in a vendor-supported training environment. It is a simulation, not a live service pilot. Use practice orders only, with real payments, guest messages and courier dispatch disabled. A vendor should show how the practice environment prevents those actions before the team starts.
- Enter the three hypothetical tickets with the arrival, due and prep times above. Confirm all are visible and ready for the exercise at noon.
- Show FIFO and record the displayed order. It should be A, B, C if the selected setting sorts by arrival time.
- Show due-time sorting and record the displayed order. It should be B, C, A if the selected setting sorts by the stated due times.
- Change B's practice due time and check whether its position and displayed time update as expected. Restore the original time before continuing.
- Walk through the B-C-A work sequence. Record the simulated finish times: 12:06, 12:22 and 12:34. Note any display or station workflow that makes those steps hard to follow.
- Practice one authorized exception, such as moving attention to a remake. Record who made the decision, how the team was notified and how the normal queue resumed.
Accept the default only if the order shown matches the chosen rule, times remain understandable after a change, and staff can explain what to do next. Also record whether the exercise reveals food sitting too long. If a condition fails, ask for a configuration change or a clear operating workaround, then repeat the relevant step.
After training, use a supervised live service period to observe actual work. Follow normal restaurant procedures for real orders; do not turn the simulation into a live test by sending practice orders to guests or couriers. At the end of service, review a small sample of late tickets and tickets finished unusually early. Note the promised time, actual completion, prep bottleneck and any override. Separate a poor queue choice from an unrealistic promise, missing ingredient or equipment delay.
Before buying, compare how the queue receives order changes from your restaurant POS system and other ordering channels. Ask for the workflow and operating costs in writing, including screens and setup, where applicable. Then compare your KDS requirements with Fleksa's available workflows using the same acceptance test.
Frequently asked questions
Is due-time sorting always better than FIFO?
No. Due-time sorting helps distinguish different promises, while FIFO may be simpler when promises and prep times are similar. Check early finishes as well as late ones.
Does the earliest due order always need to start first?
No. Prep length, food quality and available station capacity can change the right start time. A due-time queue is a priority aid, not a complete production schedule.
How should a kitchen handle an urgent exception?
Name the person who can authorize it, tell the affected stations and record the reason. Ask the vendor to demonstrate the available screen controls rather than assuming an override feature exists.
