Cooks should see in-progress orders only if the kitchen can clearly distinguish a preview from a submitted ticket and has a rule for what work may begin. If the system cannot make changes and abandoned orders obvious, keep unsent orders at the register. A few seconds of warning are not worth preparing food that the guest never ordered.
A preview is a provisional look at an order while the cashier is still building it. It is different from a submitted order intentionally held for a later course: a preview may change or disappear before anyone commits it to the kitchen. The buying decision is whether that early visibility helps your particular service enough to justify the extra control it requires.
Map the three order states
Start at the counter, not at the display. Ask the cashier to describe when an order is still being discussed, when it is ready to send, and what happens if the guest walks away. Then ask the kitchen what it should see at each point.
- In progress: The cashier has entered at least one item but has not submitted the order. Items, quantities and modifiers may still change. Treat everything visible at this stage as provisional.
- Submitted: The cashier has sent the order. The kitchen can follow its normal preparation rules, including any separate rules for held items. Confirm how the display identifies this transition.
- Abandoned: The order was never submitted and will not proceed. A preview should no longer be mistaken for active work. Ask how the system removes or marks it, and whether staff can tell that it was abandoned.
Also establish what happens when a submitted order is changed or canceled. That is a separate event from editing an unsent preview, and it needs its own kitchen procedure. Do not assume that either type of change produces a particular alert or can be recalled after removal.
Your restaurant POS system and kitchen display need to agree on the handoff. In a demonstration, watch both screens while the cashier edits the order. Ask which action makes the order official, whether a preview can be switched off, and what the kitchen sees if the cashier leaves the order unfinished.
Compare lead time with the cost of changes
Early visibility is most useful when a cook can do something reversible before submission. Reading a likely item or getting a clean pan ready may help. Starting an irreversible, made-to-order item is a different bet. The value depends on how often orders change and how much preparation can actually happen in the available time.
Hypothetical worksheet: A counter-service restaurant is considering previews for a lunch rush. Its owner estimates that an early view could give the grill cook 30 seconds of notice on 20 orders. The owner also expects two of those orders to change or be abandoned before submission. These are planning assumptions, not measured results.
| Option | Permitted early action | Estimated effect | Decision to check |
|---|---|---|---|
| No preview | None before submission | No early notice; no food started from unsent orders | Is the normal queue fast enough? |
| Read-only preview | Read the ticket and prepare a clean work area | Up to 30 seconds of notice per order; no assumed food waste | Can staff reliably wait for submission before cooking? |
| Start food on preview | Begin one $3 portion before submission | If two portions cannot be used after changes, estimated food waste is $6 | Does any demonstrated time benefit justify that risk? |
The table compares operating choices, not vendor feature claims. The $6 estimate is two unusable portions at $3 each. It includes that variable food cost only; it excludes fixed software costs, labor, equipment and other exception costs, such as remaking a submitted order. The 20 instances of early notice do not automatically equal 10 minutes saved: cooks may be busy, and preparation may overlap with other work.
On these assumptions, start with the read-only rule if the system can display previews clearly. It provides an opportunity to anticipate work without the estimated food waste. That does not establish that previews improve service; compare the workflow with no preview before allowing food preparation. If clean work-area setup does not help during a rush, the simpler no-preview option may be better.
For a real decision, write down which items have long lead times, what can be prepared reversibly, and the cost of a portion that cannot be reused. Ask the vendor for a written quote covering relevant screens, setup and ongoing charges. Compare those costs separately from the operational estimate; a quoted processing fee or software subscription alone is not the full cost of running the workflow.
Set a visible cue and permission rule
A preview should be recognizable at a glance, even when the kitchen is busy. Ask to see the actual cue on the screen your team would use: wording, placement, color or another distinction. Color alone may be easy to miss, especially from a distance. Check whether the cue remains clear when the ticket contains several items and modifiers.
Fleksa's kitchen display system is described as showing order type, item names, quantities and modifiers, with configurable timing and color indications. Ask for a demonstration of the specific preview behavior and setup you need; those general display details do not establish that unsent-order previews are available.
Write the permission rule beside the display. For example: “Preview means read only. Do not cook, plate or package until the submitted cue appears.” If you later permit a reversible task, name it explicitly. Identify who can change the rule and who handles a ticket whose state is unclear. The safe response to an ambiguous ticket should be to ask the cashier, not guess.
Make changes visible to the person doing the work. Ask how an edited quantity or modifier is presented, whether the prior version remains visible, and what happens if the order is abandoned. If the vendor cannot demonstrate a clear way for staff to recognize those events, do not authorize preparation from previews. A sound workflow does not depend on someone remembering an earlier version of the ticket.
Station routing is another boundary. A preview that reaches the grill but not the person assembling the order may create two different understandings of the same ticket. Decide which stations, if any, need early visibility, then use the guide to routing kitchen tickets by preparation station to frame the routing questions. Confirm the behavior in the proposed setup rather than assuming all screens receive the same information.
Run a modified and abandoned preview test
Before a service pilot, ask the vendor to provide a supported training environment. Use simulated orders only. The practice must not charge a card, send a guest message or dispatch a courier. Have one person act as cashier and another as cook, and observe both screens. Do not prepare actual food for the simulation.
- Record the starting state. Enter a simulated order with one item and a modifier, but do not submit it. Record whether a preview appears, its cue, and which stations see it. The cook should identify it as provisional and follow the read-only rule.
- Modify it. Change the quantity and modifier before submission. Record exactly what the kitchen sees and whether the current version is distinguishable from the earlier one. Submit the order and ask the cook to read back the final items and modifiers using the submitted cue.
- Abandon a separate order. Enter another simulated order, leave it unsent, and abandon it using the normal cashier action. Record what happens to its preview. The cook should not treat it as active work after abandonment.
- Check uncertainty. Repeat with the cook looking away during the edit or abandonment. Ask what they would do on returning to the screen. They should be able to identify the current state or stop and ask the cashier before acting.
Use these acceptance criteria: the provisional state is unmistakable; the final submitted order can be read correctly; an abandoned preview is not treated as active work; and staff follow the permission rule without guessing. Record a pass or fail for each, along with the screen behavior and any vendor setting used. If a criterion fails, change the setup or rule and repeat the simulation. If it still fails, use submitted tickets only.
Only after the simulation passes should you consider a supervised live service pilot. Brief the cashier and kitchen lead, start with the read-only rule, and agree on when to stop the pilot. During service, note confusion, changes and abandoned orders using your normal records; do not create test transactions or guest communications. Review whether early notice actually helped before expanding the rule or allowing any preparation.
Next step: Bring your worksheet and acceptance criteria to a demo. Compare your KDS requirements with Fleksa's kitchen display workflow, including whether your intended preview, change and abandonment behavior is available in your setup.
Frequently asked questions
Is a preview ticket the same as a held order?
No. A preview is an unsent, provisional order that the cashier may still change or abandon. A held order has been submitted but is intentionally scheduled or held for later preparation.
Should cooks begin preparing food from a preview?
Not by default. Start with reading or another clearly defined reversible task, if previews are available and distinct. Permit food preparation only after weighing the time benefit against changes, waste and the team's ability to recognize the final order.
What if the display does not clearly show an abandoned preview?
Keep unsent orders out of the kitchen workflow until the vendor can demonstrate a clear, workable alternative. Staff should not have to guess whether a provisional ticket still needs attention.
