Choose a whole-order view when the person managing the pass needs to see the complete meal and coordinate its release. Consider separate item tickets when cooks need a focused station view and someone can reliably bring the items back together. Many kitchens need both perspectives, but you should ask a vendor to demonstrate the exact combination rather than assume it is available.
The buying question is about grouping: what appears together as a ticket. It is different from sorting tickets by time or arranging items within a ticket. A well-sorted screen can still split an order in a way that makes assembly difficult.
Start with one order and two guests
Use a real example from your menu as the input for a demonstration. Write it down before anyone touches the screen. Identify who entered it, where the seat labels came from and which items are shared. Then compare that source record with what appears in the kitchen.
Hypothetical demonstration order: A server enters one dine-in order for two guests at one physical table. Guest 1 orders one burger with no onions. Guest 2 orders one pasta. They also share one salad. The source record contains three item lines and three total items; it labels the burger as seat 1, the pasta as seat 2 and the salad as shared. Assume the burger goes to the grill, while the pasta and salad go to another preparation station.
Those labels are inputs to the exercise, not proof that a particular system accepts or displays them. During the demo, observe whether the screen actually shows the modifier, seat and shared-item information. If a field cannot be entered or does not carry through, note that as a difference between the source record and the kitchen view.
A restaurant POS system can be the starting point for an order, but the grouping decision is made in the kitchen workflow. Ask the vendor where seat labels originate, whether shared items need a special entry and what happens when the order reaches each screen. If the entry method depends on staff remembering a workaround, include that step in your training plan and test it under realistic conditions.
Compare the views before choosing
In a whole-order view, the burger, pasta and salad stay together on one order ticket. An expeditor can see the full meal in one place. The trade-off is that a cook may have to scan past work assigned to another station. Ask whether the display can make each station's work clear without removing the context the expeditor needs.
In an item-level view, the kitchen sees separate tickets or work units for the burger, pasta and salad. That can make an individual task easier to spot, especially when different stations prepare it. The trade-off is assembly: staff need a dependable way to tell which items belong to the same order, including the shared salad.
The following worksheet compares two possible outcomes for the same hypothetical order. These are decision scenarios, not measured results or claims about any product. Each assumes the source order above is correct and that the expeditor is responsible for releasing the meal.
| Decision check | Whole-order outcome | Item-level outcome | What changes the choice |
|---|---|---|---|
| Station focus | The grill cook sees all three lines and identifies the burger. | The grill cook sees a separate burger work unit with its modifier. | Favor the item view if station staff can find their work more reliably without losing the modifier. |
| Meal assembly | The expeditor sees all three lines together and waits for each. | The expeditor matches three work units using a common order identifier. | Favor the whole-order view if matching separate units causes confusion or no complete view is available. |
| Shared item | The salad is visibly part of the order and marked shared. | The salad has its own unit, with the order link and shared label visible. | Reject a view that makes the salad look like a separate guest order or loses its association. |
For example, if the item-level demonstration preserves the order link, modifier and shared label, and the expeditor can identify all three items without searching across screens, that view may suit a kitchen with strongly separated stations. If the expeditor cannot assemble the meal confidently from those units, the whole-order view is the safer choice for that workflow, even if individual tickets look cleaner to cooks.
Also ask whether the kitchen can use a station-focused view and an expeditor view at the same time, and whether changes to one appear in the other. Do not treat a verbal promise as the result: have the vendor show the screens and the handoff. For the separate question of sending work to the right preparation area, see the guide to routing kitchen tickets by preparation station.
Trace completion through the pass
Grouping matters most when one part of an order is ready and another is not. In the hypothetical order, suppose the burger and pasta are finished but the salad is still being made. The meal is not ready to release as a complete order.
In the whole-order view, ask the vendor to show how the two finished items are marked and what remains visible. The expeditor should be able to distinguish the unfinished salad from the completed items. If a single completion action closes or hides the entire order, ask how staff avoid using it before the order is ready and how they find the order again if it is closed by mistake.
In the item-level view, the burger and pasta work units may be completed separately. The critical question is what the expeditor sees afterward. Can that person still identify the remaining salad and its parent order? Can they tell that two items are ready without mistaking the absence of their tickets for a complete meal? Ask the vendor to demonstrate the actual completion states and any available recovery path.
The expeditor owns the assembly check: compare ready items with the original order before releasing them. If something is unclear, the expeditor pauses release and asks the relevant station to verify it. The shift lead owns the exception if the team cannot account for an item. That division of responsibility prevents a cleared screen from being treated as proof that food is ready.
Fleksa's kitchen display system is linked to restaurant orders, and its public product information describes item names, quantities and modifiers on the display. Confirm the grouping, completion and recovery behavior you need in your own demonstration. You can also review the Fleksa order-management workflow when preparing your questions.
Set a pass-or-fail demonstration
Give every vendor the same source order and the same success criteria. Have the person who would normally run the pass observe alongside a station cook. Ask the vendor to use a supported training environment and confirm beforehand that the simulation will not send a real guest message, take a real payment or dispatch a courier. This is a simulated check, not a live service pilot.
- Enter and compare. Enter the two-guest order exactly as written. Pass if the relevant kitchen views account for one burger with no onions, one pasta and one shared salad, and preserve the associations needed for assembly. If seat or shared labels matter to your operation, they must be visible where the responsible staff member needs them.
- Complete part of the order. Simulate finishing the burger and pasta while leaving the salad open. Pass if the expeditor can identify the unfinished salad and connect it to the correct order without treating the whole meal as complete.
- Check a missing item. In the simulation, present only the burger and pasta for assembly. Pass if the expeditor identifies the missing salad from the order information and holds the release. The shift lead owns the exception and directs the station to verify it.
- Check a duplicate. In a separate simulation, present two salads against the one-salad source order. Pass if the expeditor spots the extra item and pauses to reconcile it. Do not count a duplicate as proof that the original salad was correctly prepared or delivered.
- Try a correction. Ask how staff handle an item marked complete in error. Pass if the vendor demonstrates a workable recovery procedure and the expeditor can again determine the order's status. Record who performs each action; do not assume every display has a recall function.
Fail the demonstration for your workflow if a required modifier or association disappears, the expeditor cannot account for all three items, or the team cannot recover from the simulated mistake using the demonstrated procedure. A workaround can still be acceptable if your staff can perform it reliably; repeat the check with them and document the extra steps before buying.
After a successful simulation, plan a supervised live service period with the shift lead watching for assembly exceptions. That is a separate check under real conditions, not a substitute for the safe practice exercise. Keep the current process available while you evaluate the new one, and agree with the vendor on support and any additional screen or setup charges before committing.
Next step: Take your own two-guest order and these pass conditions to a Fleksa KDS demonstration. Ask Fleksa to show the grouping and exception workflow on the setup you are considering before you choose.
Frequently asked questions
Can a kitchen use both whole-order and item-level views?
Possibly, depending on the product and setup. Ask the vendor to show both views at once, how they stay connected and what happens when an item is completed on either screen.
Is grouping by seat the same as grouping by item?
No. A seat groups items for one guest; an item-level view separates individual work units. Shared dishes need an order association even when they are not assigned to either guest's seat.
Who should check for missing items?
Assign the expeditor to compare the food with the order before release. The shift lead should own unresolved exceptions and coordinate the station check.
