The most useful kitchen display order identifier is usually a short ticket number paired with a clear order source. The number distinguishes active orders; the source helps staff find the right handoff path. Add a guest name only if it solves a specific problem that those two fields cannot.
Before buying, ask the vendor to show how identifiers behave when similar orders arrive together, move between stations and need correction. A readable number is not enough if it changes between the kitchen and expo or duplicates another active ticket without a reliable way to tell them apart.
Compare numbers, sources and guest names
Start with the information a cook or expediter needs to match an order, not every detail collected at checkout. A kitchen may receive a pickup order from its own website and another from a third-party source at nearly the same time. If both contain two burgers, the item list alone is a poor identifier.
A ticket number gives staff a compact reference they can call out and look for on another screen or label. Ask whether it is unique among active orders, how long that uniqueness lasts, and whether the same number appears at every preparation station and at expo. A number that resets each day may be workable, but the reset should not create ambiguity for orders still open.
The order source adds context. A short, consistent source label can help distinguish two tickets with the same number and direct staff toward the right pickup workflow. Ask how source names appear, whether similar names can be changed, and whether staff can distinguish the source from the order type. “Website” describes where an order came from; “pickup” describes how it will leave.
A guest name can help at handoff, but it is a weak primary key. Two guests can share a name, names can be misspelled, and a full name may be unnecessary on a screen visible to the whole kitchen. Ask whether the kitchen and handoff areas can show different fields. If a name is needed at pickup, consider whether a first name or another limited label is sufficient.
These identifiers support matching; they do not establish whether ordering systems connect to one another. During a demo, check the actual display at each point rather than assuming an identifier will follow an order through every part of the workflow.
Trace two similar orders from prep to expo
Hypothetical simulation: Two pickup orders arrive close together. Both contain two burgers and fries. The direct website order is ticket 42 and has one burger without onion. The third-party order is ticket 43 and has one burger with extra onion. The expected result is that staff can keep both orders distinct through preparation and handoff without using a full guest name.
| Point in workflow | Order A | Order B | Observable pass |
|---|---|---|---|
| Kitchen arrival | 42; website; pickup; no onion | 43; third party; pickup; extra onion | Both tickets are visible, and number, source and modifier are legible. |
| Preparation | Cook prepares the no-onion burger for 42. | Cook prepares the extra-onion burger for 43. | Staff can match each modifier to the correct ticket without relying on the guest name. |
| Expo | Expo finds 42 and checks its items. | Expo finds 43 and checks its items. | The same identifiers connect prepared items to the correct order. |
| Handoff | Staff use 42 and the appropriate pickup reference. | Staff use 43 and the appropriate pickup reference. | Staff can select the correct order without exposing unnecessary guest details on the kitchen display. |
The worksheet follows each order rather than treating the first screen as the whole test. The source is a useful secondary cue, while the different modifiers give the team an observable way to detect a mix-up. If the expo screen uses a different identifier, ask how staff are expected to make the connection. A separate reference can work only if the relationship is clear and consistently available where staff need it.
Include any paper ticket or bag label your operation expects to use. Check whether the reference printed there matches the display and whether a busy expediter can read it at a normal working distance. If the kitchen and counter use different references, ask for a demonstration of the handoff between them.
Run this as a simulation in a vendor-supported training environment. Use fictional orders and guest details. The practice must not create a real payment, send a guest message or dispatch a courier. If the vendor cannot isolate the workflow safely, ask for a walkthrough using prepared demonstration data instead.
Test collisions, readability and corrections
Once the basic path works, make the sample data harder. A collision does not have to mean a software failure: two outside sources might each supply the same short reference. The operational question is whether the display gives staff another dependable way to distinguish those active orders.
- Duplicate number: Simulate two active orders numbered 17 from different sources. Pass if staff can identify each by the combined number and source at prep and expo. Fail if both look alike where a decision is made.
- Similar names: Give both fictional guests the same first name. Pass if staff can match orders without guessing from the name. Fail if the name is the only visible distinction.
- Reading under pressure: Place the screen at its intended position and have a team member identify the number, source and modifier from the normal working position. Pass if each can be read without moving closer or opening an unrelated detail view. Fail if a label is cut off or easily confused with another.
- Correction: Simulate a change to an active order. Pass if staff can identify the affected ticket and understand the changed item before preparing it. Fail if they cannot tell which order changed or whether the displayed version is current.
- Removal or recovery: Ask the vendor to demonstrate the intended process when an order is canceled or a ticket is accidentally cleared. Pass if staff can identify the affected order and know the next action. Fail if the demonstration leaves an unresolved match.
Agree on the expected outcome before each scenario. Note which screen or label staff used and where they hesitated. A feature that exists in a menu but requires several steps at expo may not meet your service requirement. Do not assume that every system supports recall or cancellation handling in the same way; ask what the team must do when a function is unavailable.
After practice, a supervised service pilot can check the workflow under real conditions. Set responsibilities and an escalation path first. The simulation is for safely learning and checking the sequence; the live pilot is a separate operational decision, not a substitute for a safe practice environment.
If orders go to more than one station, use the guide to routing kitchen tickets by preparation station alongside this identifier check. Routing determines where work appears; identifiers help staff match the pieces back to the same order.
Set a minimum identifier and privacy requirement
For a restaurant with multiple order sources and a shared expo, a reasonable starting requirement is a readable ticket number plus a source label on every screen where staff must match work. Keep order type, items, quantities and modifiers visible as operational information. They help staff prepare and hand off the order, but they should not be the only way to distinguish two similar tickets.
This recommendation assumes the number and source together distinguish active orders and remain consistent across the relevant screens. If the demonstration shows a collision that those fields cannot resolve, ask the vendor for another short reference or a documented matching procedure. Do not add a full guest name by default merely to compensate for an unclear identifier.
Review the display from the perspective of each role. A cook needs to identify and prepare the ticket; an expediter needs to assemble it; counter staff may need an additional pickup reference. Ask which guest fields each role can see, whether fields can be hidden, and what appears on printed tickets or labels. Also ask who can change those settings and how the team will handle a guest who cannot provide the usual pickup reference.
For a vendor conversation, bring a short acceptance list:
- Show the identifier on the initial ticket, each relevant station and expo.
- Explain uniqueness, resets and what happens when two sources use the same number.
- Demonstrate the team's process for a change, cancellation and accidental clear.
- Show which guest details appear by role and on any printed output.
- Confirm the proposed setup, any additional screen or setup charges, and the support available for training.
Fleksa offers a kitchen display linked to restaurant orders. Its public KDS description includes order type, item names, quantities and modifiers, as well as timing indications. Ask to see the identifier and privacy settings for your intended setup rather than assuming they follow from those display details. It is also worth checking how the proposed workflow connects with your restaurant POS system and broader restaurant management software.
Next step: Bring the two-order worksheet and your acceptance list to a Fleksa kitchen display system conversation. Compare your requirements with Fleksa and confirm current availability before choosing a workflow.
Frequently asked questions
Is a ticket number enough on its own?
It can be if it reliably distinguishes every active order wherever staff need to match it. With multiple sources, a source label provides another useful cue. Test what happens when outside references repeat.
Should the kitchen display show guest names?
Show a name only where it serves a defined task. Ask whether a limited name can be reserved for handoff while the kitchen uses a number and source. Names alone can be duplicated or misspelled.
How should we practice a corrected order?
In a vendor-supported training environment, use fictional data to change an active sample order and have staff identify the affected ticket and updated item. Ensure the simulation cannot take a real payment, message a guest or dispatch a courier.
