A good kitchen display override gives an authorized person a way to change a ticket’s priority and gives the kitchen enough context to act on it. Before buying, decide who can make that change, what reason they must provide, and where cooks will see both the new priority and the ticket’s earlier place in the queue.
Ask each vendor to demonstrate the complete path, not just a button that marks an order as urgent. The important moment is what happens after that button is pressed: which screens change, what the team sees, and what happens if two people make conflicting changes.
Decide who can override the queue
Start with one accountable role. In a small restaurant, that might be the shift manager. In a larger operation, an expeditor may make the change while the manager handles exceptions. Name a backup for breaks and busy periods; an approval process that depends on someone who has left the line can slow service.
Separate a routine rush rule from an override. A rule sets the normal way tickets become urgent, perhaps according to elapsed time. An override is a person’s exception to that normal order. It needs a clear reason because moving one ticket forward can delay another guest’s meal.
Agree on the situations that justify an exception. Examples include a remake that needs to catch up with the rest of a party’s food, or a handoff error that left a finished item waiting. A guest asking for faster service may require a manager’s judgment rather than an automatic jump to the front.
Also decide what cooks can change themselves. If every cook can adjust priority, the line may respond quickly, but conflicting changes become harder to manage. If only a manager can do it, ask how the manager sees the queue and how the line requests help. Neither permission model is automatically right for every shift.
Map the override from request to kitchen
The following worksheet is a hypothetical example, not a description of a particular product. A shift manager wants to move a remake ahead of other tickets. The restaurant’s requirement is that cooks can see why it moved and where it was before the change.
| Step and owner | Action or decision | What the team needs to see |
|---|---|---|
| Cook requests help | Flags ticket B as a remake to the shift manager. | Ticket identity and the item that needs attention. |
| Manager reviews queue | Checks that B is third, behind A and C, before changing its priority. | Original position: third behind A and C. |
| Manager overrides | Moves B to first and records “remake for delayed plate.” | New priority, reason, and who made the change. |
| Cook acknowledges | Reads the updated display and starts the remake. | B first; A and C still visible in their resulting order. |
| Manager follows up | Checks the delayed tickets and communicates any change to the front of house. | A clear current queue and a way to review the override. |
The table separates the request, the decision and the work on the line. In this example, moving B from third to first leaves A second and C third. The manager chooses to accept that delay because the remake is holding up a plate. If the reason or original position is only available in a back-office report, decide whether that is enough; the cook needs useful context during service, not only afterward.
Ask the vendor to show where the reason appears, how long it remains visible, and whether the person making the change is identified. Can the manager choose a reason, enter one, or both? Can staff find the earlier queue position without reconstructing it from memory? If the display cannot show an earlier position, ask what record is available and decide whether a manual note is acceptable.
Keep the reason short enough to read on a busy line. “Remake for delayed plate” tells a cook more than “urgent.” Avoid using the reason field for unnecessary guest details. Decide who tells the front of house when the change affects another order; a kitchen screen does not replace that conversation.
For the surrounding order workflow, review the kitchen order management documentation and ask how your own queue would be set up. If different stations see different parts of an order, include each affected station in the demonstration.
Compare approaches and their real operating demands
Use the same ticket scenario with each vendor. A priority label alone, a permission-controlled change with a visible reason, and a verbal manager call are different operating approaches. Compare them on what the staff must do, not just on whether a salesperson can demonstrate a rush control.
- Staff effort: Count the steps to request, approve, enter and communicate an exception. Ask how a backup manager takes over and how a cook knows which version of the queue to follow.
- Guest impact: Discuss the ticket moved forward and the tickets moved back. Can the front of house get a useful update without interrupting the line repeatedly?
- Traceability: Ask whether the display or an accessible record shows the reason, actor, earlier position and final priority. Decide which details must be visible during service and which can be reviewed later.
- Cost dependencies: Request a written operational quote covering software, necessary screens, setup, training and any recurring support or extra-screen charges. Ask which costs are fixed, which vary with use, and what exception costs could arise, such as a replacement device or extra training.
- Vendor limits: Ask about device requirements, station setup and behavior if a screen loses its connection. Do not assume a priority change, its reason or the earlier position will appear everywhere you need it.
When comparing quote totals, use the same period and equipment assumptions. Separate one-time setup from recurring charges, and identify excluded items. Processing fees and sales are separate measures; neither is the total cost of operating a kitchen display. Ask vendors to explain costs they cannot yet quote rather than treating them as zero.
Fleksa offers a kitchen display system linked to restaurant orders. Its public product information describes order type, items, quantities, modifiers, future held orders and configurable timing or color indications. Ask for a demonstration of override permissions and visibility in your intended setup. For Fleksa pricing, see the plans page, checked November 2026, and request a current quote for the setup you need.
Square describes kitchen tickets, timers, station routing and expeditor functions. Toast also offers a kitchen display product. For either, ask to see the same override scenario and obtain a written quote; those general product descriptions do not answer who can change priority or how the reason appears.
A practical decision follows from your requirements. In the hypothetical restaurant above, the manager should favor an option that shows cooks the new priority and reason while preserving an accessible record of the earlier position. If a product cannot do that, the owner must decide whether a manager’s written queue note and verbal call are reliable enough for the shift. A lower quote alone would not satisfy the stated visibility requirement.
Test conflicting changes and plan the fallback
Before selection, ask the vendor to run a simulation in a supported training environment. Use sample tickets only. The simulation must not take a real payment, send a guest message or dispatch a courier. Invite the manager, backup and a cook who will actually read the screen.
Set an acceptance rule before the demonstration: one final priority must be clear to every affected user, and the team must be able to tell why it is in effect. Agree with the vendor how the system should resolve conflicting changes. The acceptable outcome might be one change taking precedence with a visible record, or one user being told that the change failed and needs review. Do not assume which behavior the product uses.
- Place a sample ticket in a known queue position. Note the position and what each affected screen shows.
- Have the manager and backup attempt different priority changes at the same time, using different reasons. Keep the attempts close enough together to test a genuine conflict.
- Check the final ticket state on each relevant screen. Ask both users whether their actions succeeded, failed or need review. Check what a cook can read without leaving the display.
- Find the earlier position, the final priority, the reason and the person associated with the final change. Also ask whether the other attempt is recorded and where.
- Repeat with one screen disconnected in the training environment, then reconnect it. Ask how staff are alerted to a stale view and how the screen reaches the current state. Do not assume offline changes are supported.
Pass: The observed behavior matches the agreed conflict rule, all affected screens show the same final state, and staff can find the required reason and earlier position. Fail: Screens disagree, an outcome is ambiguous, or a required detail is unavailable. Record screen views, messages and the final queue order; note any manual step needed to resolve a mismatch. A verbal assurance is not the same as seeing the workflow.
If the system fails your requirement, use a defined fallback rather than improvising at the pass. For example, designate the shift manager as the only person who calls priority changes, have that person write the ticket, earlier position and reason on a shared shift note, and verbally confirm the resulting order with each affected station. Decide who updates the front of house. This adds work and can introduce mistakes, so make that trade-off part of the buying decision.
After simulation, practice the agreed process with staff. A later supervised service pilot is separate: use normal operating safeguards, watch how the team handles actual exceptions, and review the shift notes afterward. Set a point at which the manager will stop using the new process and return to the fallback if the queue becomes unclear.
Take your completed worksheet and acceptance rule to Fleksa’s kitchen display team. Compare the demonstrated workflow with your current process and ask which capabilities apply to your setup.
Frequently asked questions
Who should be allowed to change ticket priority?
Choose an accountable role, such as a shift manager or expeditor, and name a backup. Balance the need for fast action against the risk of conflicting changes.
Does a priority color explain why a ticket moved?
Not necessarily. Ask where the reason appears, who can see it during service, and whether staff can find the ticket’s earlier queue position.
What if two managers change the same ticket?
Ask the vendor to simulate conflicting changes and show the final state on every affected screen. Set a manual fallback if the result or reason is unclear.
