Use a sequential workflow when the next station should act only after an earlier station finishes and that handoff needs a clear signal. Use parallel visibility when stations benefit from seeing the order early and can manage their own timing without mistaking advance notice for permission to start.
The distinction matters most when one station depends on another. A bake station may need to know a pizza is coming, but an early ticket does not mean the pizza is ready for the oven. Decide whether your kitchen needs an early warning, a controlled handoff, or both before you choose the screen behavior.
Station routing and sequencing are separate decisions. Routing determines which stations receive an item. Sequencing determines when each station sees it or receives a ready-to-work signal. For the routing decision itself, see the guide to routing tickets by preparation station.
Map a pizza from prep to bake
Consider a hypothetical example: one pizza moves through dough preparation, topping, and baking. Assume each station has a separate worker and display. Prep must finish before topping can begin, and topping must finish before baking can begin. The times below describe work on one pizza, not an entire kitchen's capacity.
Assume prep takes two minutes, topping takes three, and baking takes six. There is no waiting, travel time, oven warm-up, interruption, or rework. The earliest finish is therefore 11 minutes after prep starts. Showing all three stations the ticket immediately does not shorten those dependent steps by itself.
| Stage | Work and assumption | Sequential handoff | Parallel visibility |
|---|---|---|---|
| Prep | Form dough; 2 minutes | Prep receives the task first. | All stations see the order; prep starts. |
| Topping | Add toppings; 3 minutes after prep | Topping receives a ready signal after prep completion. | Topping sees the order early but waits for the prepared dough. |
| Bake | Bake; 6 minutes after topping | Bake receives a ready signal after topping completion. | Bake sees the order early but waits for the topped pizza. |
The table separates seeing a ticket from being able to work on it. In either column, the pizza still needs the physical handoff. If prep finishes at minute two and topping finishes at minute five, bake can start at minute five and finish at minute 11 under the stated assumptions.
For this pizza, choose a sequential ready signal if the oven worker uses the screen as the active work queue and an early ticket could be mistaken for a ready pizza. The result follows from the dependency: baking cannot begin until topping is done. If the oven worker also needs advance notice to plan space, ask for an early view that remains clearly separate from the ready queue.
That hybrid is a requirement to demonstrate, not an assumed setting. Ask whether the product can show upcoming work without placing it among items ready to bake, and whether that distinction survives a busy queue. If it cannot, decide whether a separate verbal or physical handoff is reliable enough for your team.
Compare visibility, handoffs, and queues
Sequential: a clearer ready queue
In a sequential design, the next station receives a task or ready signal after an earlier step is completed. This can keep a worker's active queue focused on things they can act on now. It can also make responsibility clearer: prep completes its step, then topping takes over.
The tradeoff is that a missed completion can hold back a perfectly good pizza. The oven worker may see little warning of incoming work if the system does not offer a separate upcoming view. A queue that looks quiet may reflect a blocked handoff rather than a lack of orders.
Before choosing this model, decide exactly what a completion means. Is it a tap when the dough is formed, when it is placed on the topping counter, or when the topping worker accepts it? A consistent physical rule matters more than a neat diagram. If staff tap before the item actually moves, the next screen can become an unreliable promise.
Parallel: early visibility with a timing rule
In a parallel design, multiple stations see the item at once. That can help people anticipate workload, particularly when they need to prepare space or coordinate several dishes for one order. It can also let independent components start together: a salad station does not necessarily need to wait for pizza dough to be formed.
The risk is a queue full of work that is visible but not ready. If the oven worker treats every displayed pizza as an immediate task, the screen competes with the actual handoff. Staff then need a dependable convention: for example, the pizza becomes actionable only when it arrives on a designated rack and its ticket is identified.
Ask how the display distinguishes upcoming, ready, and completed work. If it cannot distinguish them, use parallel visibility only when your physical process makes readiness obvious and staff can keep the queue manageable. Do not assume a timer or color on a screen automatically represents the status of the preceding station.
Choose per item, not only per kitchen
A ticket can contain both dependent and independent work. The pizza's prep, topping, and bake steps depend on one another; a separately prepared salad may be able to start as soon as its station receives the order. Ask whether the system can handle those different needs within one order and how an expeditor sees the combined progress.
Also ask what happens when a station is busy. Does a newly released item join the end of its queue, keep the order's original position, or use another rule? The answer affects whether an older pizza gets buried behind newer work. Have the vendor show the actual ordering rule rather than relying on a label such as “priority.”
Trace a missed completion and a rework request
Keep using the hypothetical pizza. At minute two, prep places the dough on the topping counter but forgets to mark its step complete. In a strictly sequential setup, topping may not receive its ready signal. The physical item is available, yet the screen says there is no new task. If topping starts anyway, the screen and kitchen can disagree.
Decide who notices that mismatch and what they should do. A workable operating rule might require topping to tell prep that the dough arrived without a screen handoff. The responsible worker then corrects the status using the method the vendor demonstrates. Ask what happens if the original worker has left the station, and whether a supervisor can correct the step without completing the whole order.
Now consider a separate rework event: after topping marks the pizza ready, the bake worker spots the wrong topping before the pizza enters the oven. The useful outcome is that topping receives a clear request to fix the same pizza, bake does not treat it as ready meanwhile, and the team can tell when the corrected pizza returns.
Ask the vendor to show whether a task can be returned to a prior station, how the reason is conveyed, and whether the original ticket remains visible. If the product cannot do that, agree on an alternative such as a verbal call and a designated rework area. Specify who updates the display and who confirms the corrected handoff. A workaround is acceptable only if staff can use it consistently during a rush.
Test a second outcome too: what if the mistake is found after baking starts? The team may need a remake rather than a simple return to topping. Ask how staff distinguish the remake from the original item and prevent both from being treated as finished. Do not assume a display can recall, reroute, or cancel a step; make each action part of the demonstration.
Use a decision worksheet and a safe demo
Write down your answers before discussing screen layouts. Start with one representative item and its actual path through the kitchen.
- Dependency: Which step cannot begin until another finishes? For the hypothetical pizza, topping depends on prep, and bake depends on topping.
- Advance notice: What can the next station usefully do before handoff? The bake worker might plan oven space, but cannot bake the unfinished pizza.
- Queue rule: Should an early item appear with active work? In the example, no: the oven's active queue should mean ready to bake.
- Failure response: Who spots a missing completion or rework request, and how is the status corrected? Assign a named role for each response before service.
- Decision: For the stated pizza assumptions, request sequential ready signals, plus a separate upcoming view if advance notice is useful. If that combination is unavailable, compare a parallel view with a disciplined physical handoff against the risk of delayed visibility in a sequential queue.
Repeat the worksheet for an item with independent components. If stations can genuinely work at the same time, parallel visibility may be the more useful starting point. The decision is not about making every ticket follow the same path; it is about making the display match what each worker can do.
Bring your worksheet to each vendor and ask for the same demonstration. Show a normal pizza, a missed completion, and a rework request. Ask the demonstrator to explain what each station sees before and after every action, what happens to queue position, and who can correct an error. Include an order with a modifier so the people doing the work can judge whether the details remain clear at each handoff.
Use a vendor-supported training environment for these simulations. Confirm first that practice tickets cannot trigger a real payment, guest message, or courier dispatch. A simulated check verifies what you can observe in that environment; it does not prove the setup will work under service pressure. Afterward, plan a supervised live service pilot with staff assigned to monitor handoffs and a documented fallback if the display does not match the physical kitchen. A live pilot involves real orders, so agree on normal payment, communication, and dispatch procedures before it starts.
For context, Fleksa offers a kitchen display system linked to restaurant orders. Its public product information describes order type, item names, quantities, modifiers, held future orders, and configurable timing and color indications. Ask which setup can support your sequence, upcoming view, and error-handling requirements; those details need a demonstration. The kitchen display documentation can help frame your questions.
Get a written quote for the screens, setup, support, and any other charges in your intended configuration. Separate fixed charges from usage-based and exception charges, and ask what could change the quote. The kitchen display cost guide is a useful starting point for the cost discussion. Compare your requirements with Fleksa and ask for a demonstration of the relevant workflow.
Frequently asked questions
Does parallel visibility mean stations work at the same time?
No. Stations can see an item at the same time while still waiting for a physical prerequisite. Parallel work is possible only for tasks that do not depend on an unfinished earlier step.
Can a sequential workflow still give the next station advance notice?
Possibly. Ask whether the system offers an upcoming view separate from the active ready queue, and have the vendor show how staff distinguish the two.
What should we do if a station forgets to complete a step?
Use an agreed handoff rule to alert the responsible worker, then correct the status using the procedure demonstrated for your setup. Practice the situation in a safe training environment before a supervised service pilot.
