Expo should prioritize a ticket when a specific, approved problem calls for food to move ahead of the normal queue—not simply because someone asks loudly. Set the eligible reasons before service, name who can approve a rush, and tell each affected station exactly which item needs attention and when.
The display matters as much as the rule. A useful rush indication should be visible where the work happens, distinguish an urgent item from the rest of the ticket where possible, and give expo a way to confirm that stations understood. Ask vendors to demonstrate the behavior with your menu and workflow; a color change alone does not prove that the right cooks will see or act on it.
Choose rush reasons and an approver
Start with a short list your team can apply consistently. For example, you might allow a rush for a remake after a preparation error, a delayed item needed to complete a table’s meal, or an order whose promised handoff time is at risk. These situations have a clear service problem and an action the kitchen can take.
Other requests deserve a conversation rather than automatic priority. A guest asking for speed, a server submitting an order late, or a manager wanting a particular table served first can push the delay onto other guests. Decide which exceptions you will allow and who can authorize them. If everything becomes urgent, the rush signal stops helping the line choose its next task.
Give one role final approval during each shift. Expo is a sensible choice when that person can see the whole queue and speak to the stations. In a smaller kitchen, the lead cook may hold that responsibility. The approver should know the reason, the affected items, and the requested serving time before changing the priority. If expo is away, name a backup rather than leaving every station to make a separate decision.
Also define what rushing does not mean. It does not authorize a cook to skip a required preparation step or send an incomplete dish. It is a queue decision, not permission to compromise food safety or dish quality. When the requested time cannot be met, expo should tell the front of house what the kitchen can realistically do.
A decision worksheet
The following is a hypothetical example. Assume a dine-in table has received most of its meal, but one grilled entrée was missed. A replacement needs six minutes on the grill and one minute at garnish. The other dishes are already with the guests, so there are no held companion items. Expo can approve a rush, and both stations are staffed. These times are planning assumptions, not guarantees.
| Decision point | Input | Result |
|---|---|---|
| Reason | One entrée was missed | Eligible as a delayed item completing the meal |
| Scope | Only the replacement entrée remains | Prioritize that item, not unrelated work |
| Station sequence | Grill: 6 minutes; garnish: 1 minute afterward | Tell grill to start; alert garnish to expect the item |
| Timing | Seven minutes of consecutive work, with no waiting assumed | Use seven minutes as the earliest planning estimate; allow for queue and handoff delays |
| Approval and update | Expo approves and checks with both stations | Front of house receives an estimate after the cooks confirm capacity |
The seven-minute estimate includes only the assumed grill and garnish work. It excludes waiting for equipment, handoff time and any remake or interruption. If the grill cannot start immediately, expo should add the expected wait before giving an estimate. The worksheet leads to item-level priority because the other dishes have already been served; moving an entire ticket would add no useful instruction.
Trace the delayed dish from expo to each station
Follow the hypothetical entrée from the moment expo learns it is missing. First, confirm that the replacement is needed and that it has not already been started. Expo approves the reason and identifies the item, its modifiers and the table. A rush without those details can produce the wrong dish faster.
Next, expo tells the grill what to make and asks when it can start. Garnish receives advance notice that the entrée is coming, but should not be asked to finish it before the grill work is done. Expo owns the handoff between those steps and checks that the finished plate reaches the right table. If the estimate changes, the front of house needs the revised answer rather than an old promise.
When evaluating a kitchen display system, ask the vendor to show each screen involved in that sequence. Does the priority appear on the grill view, the garnish view and expo’s view? Can the indication identify the item and reason, or does it only mark the whole order? Does a station have to open a ticket to see it? Ask what happens if a cook is already looking at another part of the queue.
Agree on an acknowledgment rule too. A visible marker is useful, but expo still needs to know that someone has accepted the work. Your process might call for a verbal response, a display action if available, or both. Ask whether the system records or displays any acknowledgment, and decide whether that behavior fits the pace of your kitchen.
Station routing is a separate decision from urgency. An item must reach the people who prepare it before a priority marker can help them. Use the guide to routing kitchen tickets by preparation station to map the normal path, then test rush behavior on top of it. Fleksa’s kitchen display documentation is another place to start a conversation about the order information your team needs to see.
Compare full-ticket and individual-item priority
A full-ticket rush tells stations that the order as a whole needs attention. That can be practical when every remaining item is late and the meal should leave together. It can also be a reasonable manual fallback when the display cannot mark individual items, provided expo explains which work actually needs to move.
Its weakness is ambiguity. A ticket may contain a cold appetizer that is ready, an entrée on the grill and a side that should not be started yet. If every station sees the same urgent marker, cooks may speed up work that is already on time or prepare food too early. Expo then has to correct the misunderstanding while managing the rest of the line.
Individual-item priority is more precise when only one dish is blocking service. It lets the team direct attention toward the delayed work while leaving unrelated items in their normal sequence. Precision still requires coordination: a cook needs to know whether to start immediately, prepare for a later handoff or wait for expo’s call.
Do not assume a display offers both choices. In a demonstration, ask the vendor to mark a single delayed item, then mark a whole ticket. If either action is unavailable, ask how staff can communicate the same distinction without making the screen misleading. Can a note identify the item? Will that note appear at every relevant station? Is the note prominent enough during a busy service? Choose a workflow your team can follow even when the display’s options are narrower than your ideal.
Also ask how priority is removed or resolved. The kitchen needs a clear point at which the rush is no longer active: for example, after expo confirms the replacement has gone out. Avoid relying on an old marker that might make a later viewer think there is still unfinished urgent work. Recalling a completed ticket, if a system offers it, addresses a different problem: recovering work marked complete by mistake. It does not by itself establish a rush rule.
Protect held items and prepare a fallback
A rush can collide with a hold. Suppose a table has an entrée that must be remade, while another item is intentionally waiting for a later course. The operator must decide whether to rush only the remake or change the course timing as well. The safe default for the workflow is to keep the held item on its agreed schedule unless expo explicitly changes that instruction after speaking with the front of house.
Ask the vendor to demonstrate what staff see when a held item and a rush request appear on the same order. Does marking the ticket urgent change the held item’s timing or visual state? Can stations distinguish “prepare now” from “keep waiting”? If the system cannot express that distinction clearly, use an agreed verbal instruction and have expo verify both actions. Fleksa’s public product information describes future held orders and configurable timing and color indications; ask how those settings behave with priority in your own setup.
Write the fallback down before service. For example, if a priority marker is unavailable or unclear, expo can announce the table, item, reason and requested action directly to each affected station. Each station repeats back the instruction. Expo then tracks the item on the normal ticket and tells the front of house when the estimate changes. Use a clearly designated paper note if your kitchen needs a visual reminder, and remove it when expo confirms the item has left. Avoid putting guest-sensitive details on a note visible outside the kitchen.
Practice before relying on the rule
In a vendor-supported training environment, simulate the missed entrée and the separate held-item situation. Use practice orders and settings that cannot create a real payment, guest message or courier dispatch. Have one person act as expo and another observe each station view. Check whether the correct item is visible, whether the hold remains clear, and whether staff can say who owns the next action. If the training setup cannot safely prevent real actions, ask the vendor for another way to demonstrate the workflow.
Then run a supervised live service pilot using your normal service safeguards. A live pilot involves real orders, so it is not the same as a simulation. Limit the pilot to a shift where an experienced lead can watch the queue, use the manual fallback when needed and collect staff feedback afterward. Review missed acknowledgments, conflicting instructions and food prepared too early before changing the rule.
Bring your rush reasons, station map and held-item example to a Fleksa kitchen display demonstration. Ask the team to walk through item and full-ticket priority, station visibility and your fallback, then compare the demonstrated workflow with your written requirements.
Frequently asked questions
Who should be allowed to rush a ticket?
Choose one accountable role per shift, such as expo or the lead cook, and name a backup. Other staff can request a rush, but the approver should check the reason and the effect on the queue.
Should a rush apply to the whole ticket?
Use the narrowest instruction that solves the problem. A whole-ticket rush can fit when all remaining items are late; an item-level instruction is clearer when only one dish needs to move. Confirm what your display supports.
What if a station misses the rush marker?
Expo should contact the station directly, confirm the item and requested action, and get an acknowledgment. Document that verbal fallback and practice it before relying on the display during service.
