To coordinate held and fired courses, the kitchen needs more than a ticket on a screen. Staff must be able to tell which items are waiting for permission to start, which have been fired, when that happened, and who has acknowledged the instruction. Evaluate a kitchen display by following those signals through a complete meal, including a late change.
Course firing answers when preparation should start. Station routing answers where the work appears. Both matter, but a ticket reaching the right station does not prove that the cook knows whether to start it. For the routing decision, use the guide to routing kitchen tickets by preparation station.
Map who holds, fires, and acknowledges a course
Start with your current service, not a feature list. Pick a common two-course meal and write down who sends the order, who decides when the entree should start, and how the kitchen confirms it has received that decision. Include the expeditor if you use one.
For example, a server may enter appetizers and entrees together, with the entrees held. Later, the server or expeditor asks the kitchen to fire the entrees. The important question is what happens between that request and a cook beginning work. Does someone acknowledge it? Can the person coordinating service see that acknowledgment, or must they ask across the pass?
Define each signal in ordinary language before the demo:
- Held: The kitchen knows the item belongs to the order, but it is not yet authorized to start.
- Fired: The instruction to start has been given. Decide who is allowed to give it.
- Acknowledged: The responsible person has seen the instruction. Agree whether this is a screen action or a verbal confirmation.
- Ready or complete: The item has reached the point your team defines, such as ready for the pass. This is different from acknowledging the fire.
Also decide what timing information you need to preserve: order entry time, fire time, acknowledgment time, or time since firing. A running timer is useful only if everyone knows which event started it. Ask what remains visible after an item changes state and who can see it.
Check how the restaurant POS system passes the initial order and later instructions to the kitchen. If the front-of-house team uses a separate verbal instruction as a backup, include that step in the workflow rather than assuming the screen replaces it.
Compare screen states using a two-course chart
The following timing chart is hypothetical. The inputs are one party, two appetizer items, two entrees, and a server who is responsible for requesting the entree fire. The times are instructions for a demonstration, not measured preparation times or a claim about any product.
| Time | Event | What staff need to know | Question for the demo |
|---|---|---|---|
| 6:00 | Order entered; appetizers sent and entrees held | Appetizers may start; entrees must wait | How are held entrees distinguished from active work? |
| 6:05 | Appetizers in preparation | The entree hold still applies | Can the expeditor see the hold without interrupting a cook? |
| 6:12 | Server requests entree fire | The kitchen has an instruction to start | Where does the fire appear, and is its time visible? |
| 6:13 | Responsible cook acknowledges the fire | The instruction has been seen | Can the coordinator distinguish acknowledgment from completion? |
The chart separates the request at 6:12 from acknowledgment at 6:13. That distinction matters when a dining-room employee assumes an entree is underway but the kitchen has not seen the instruction. Ask the vendor to show which timestamps are recorded and which are visible during service, rather than accepting a general answer that the system has timers.
On each relevant screen, look for a clear difference between a held entree, a newly fired entree, and an item already being prepared. Ask whether the distinction uses text as well as color, whether modifiers remain attached, and whether a busy cook can identify the change without opening several screens. If the same course involves more than one station, ask how each station sees its own work and how the expeditor sees the whole course.
Fleksa's kitchen display system describes order types, item names, quantities, modifiers, future held orders, and configurable timing or color indications. Ask to see how your proposed setup handles course holds and fire instructions specifically; a future held order and a held course within an active meal are different situations.
Trace an entree added after preparation starts
Continue the same hypothetical meal. After the appetizers are in preparation but before the entrees are fired, the party adds one entree. The server needs to add it without making the kitchen mistake it for a separate, immediately active course.
Ask the vendor to demonstrate the actual steps the server would take. Does the added item appear with the original party and course? How does the kitchen know it is new? Can it be held until the planned fire, and what does the expeditor see? Do not assume that changing the POS order automatically produces the right instruction at every screen.
Then change the sequence: add that entree just after the original entrees are fired. Ask whether staff must fire the added item separately, whether the display shows its later start, and how the kitchen recognizes that it may finish after the others. If the screen does not preserve that distinction, the team needs a clear manual handoff or a different workflow.
Also walk through a correction to an item and a canceled item. Ask how the old and new instructions are distinguished, whether a cook must acknowledge a change, and what the coordinator sees if work has already begun. Do not treat an edited order as proof that the cook saw the edit.
Agree on a fallback for a missed or unclear signal: who calls the station, who updates the service team, and where the current instruction is recorded. A fallback can be verbal, but it should have an owner. Ask how a vendor handles a screen interruption and what staff should do if the order state is uncertain after it returns.
Set acceptance tests before choosing
Turn the chart into a shared demonstration for every vendor. Use a vendor-supported training environment with simulated orders only. Confirm that the exercise cannot trigger a real payment, guest message, or courier dispatch. Have someone unfamiliar with the test script act as the cook; the person entering the order should not coach them through the screens.
- Identify the hold. Enter both courses and ask the cook which items may start. Acceptance: the cook correctly identifies the held entrees without treating them as missing tickets.
- Fire and acknowledge. Send the fire instruction and ask the cook to identify it and follow the agreed acknowledgment step. Acceptance: the coordinator can tell the difference between an instruction sent and one acknowledged.
- Read the timing. Ask both people what each visible timer or timestamp represents. Acceptance: their answers match the workflow, and the team can find the fire time or use an agreed alternative.
- Make the late addition. Add an entree before the fire, then repeat with an addition after the fire. Acceptance: the cook and coordinator can identify the new item and agree whether it is authorized to start.
- Handle uncertainty. Simulate an unclear instruction and rehearse the fallback. Acceptance: staff know who contacts the station and how they confirm the current instruction.
Record the steps, screen views, and any manual work needed for each result. If a vendor cannot show a state or timestamp your operation requires, decide whether the fallback is workable during a rush. A lower quote is less attractive if it leaves the expeditor chasing every fire; an extra screen is not automatically worthwhile if it adds no useful visibility. Request written quotes covering the proposed screens, setup, training, and recurring charges, and ask which exception costs could arise.
After the simulation, train the team and run a supervised service pilot with the agreed workflow. This is live service, not a practice environment: use real orders only when staff are ready to manage them, watch the handoffs, and keep the fallback available. Review any confusion with the team before expanding the process.
Next, write down your required hold, fire, acknowledgment, and change-handling steps. Compare them with a demonstration of Fleksa's restaurant management software and ask the vendor to show the workflow on the setup you are considering.
Frequently asked questions
Is a held course the same as a missing ticket?
No. A held course is known to the system or team but is waiting for permission to start. A missing ticket has not reached the person who needs it. The display and fallback should help staff tell the difference.
Should the fire time or order time drive the timer?
That depends on what the timer is meant to measure. Order time shows how long the order has existed; fire time shows how long the kitchen has had the start instruction. Ask which event starts each timer and whether both times are available.
What if a late entree cannot be held separately?
Ask the vendor to show an alternative and have the team practice it in the simulation. If a manual call and confirmation are necessary, assign responsibility and decide whether that extra step is acceptable during service.
