Cooks need to see an item’s modifiers and preparation notes while they can still identify the item, quantity and ticket. To evaluate a kitchen display system (KDS), put realistic sample tickets on the screens your staff would use, then ask cooks to explain what they would prepare and where any uncertainty remains.
A useful display keeps the instruction attached to the right item, makes the full instruction accessible, and shows it to everyone responsible for carrying it out. If a cook has to guess which item a note belongs to, or an essential instruction disappears from a station’s view, the workflow needs a fix before you rely on it in service.
Build sample tickets around your menu
Start with a few items that reflect how your kitchen actually works. Include a simple modifier, an item-specific kitchen note and a longer instruction. Add at least one ticket with two similar items so the cook has to distinguish which instruction belongs to which plate.
The following tickets and decisions are hypothetical. They are examples for a simulated check, not results from a product test. Enter them only in a vendor-supported training environment. The simulation must not trigger a real payment, guest message or courier dispatch.
| Sample ticket | Instruction to enter | What the cook should identify |
|---|---|---|
| Two chicken sandwiches | One with no tomato; the other with extra tomato | Which modifier belongs to each sandwich and the quantity of each |
| One burger and one side salad | Burger: sauce on the side | That the note applies to the burger, not the salad |
| One grain bowl | Guest reports a sesame allergy; ask the lead to confirm ingredients and preparation before starting | The complete safety-related instruction and the need to pause for confirmation |
| Two similar bowls | First: no onions. Second: no onions, dressing on the side, and vegetables warmed separately | Both item identities and every instruction for the second bowl |
The table gives you a compact acceptance worksheet. The last row is deliberately harder: a display may show the first few words of both instructions but hide the difference that matters. Ask the cook to read the ticket from the normal working position, then describe the order without prompting. Record whether the cook can identify the item and all its instructions, not just whether text appears somewhere on the screen.
Use your own menu names and common requests too. Include a long name, a quantity greater than one and a note written in the language or shorthand your team uses. If your ordering channels collect instructions differently, ask the vendor to enter representative examples through each relevant channel in the training environment.
Agree on the intended meaning before the demo. For example, decide whether a quantity of two with one modifier means both items receive that modifier or whether the items need separate entries. The display cannot resolve an ambiguous order entry by itself.
Check hierarchy, wrapping and truncation on each screen
Run the same samples on the screen sizes and layouts you are considering. Look at the ticket when the screen has several other tickets visible, not just when a single order fills the display. A note that looks clear in an empty demo may be much harder to follow during a busy period.
For each item, follow the visual path from quantity to item name to modifier to note. The cook should be able to tell where one item ends and the next begins. Watch for a note placed between two items without a clear attachment, similar text styles that blur the distinction between an item and its instruction, or a quantity that appears far from the item it describes.
Then look at the full length of each instruction. Does the text wrap onto additional lines? If it is cut off, is there an obvious way to open the complete text while preserving the item and ticket context? Ask the vendor to demonstrate the actual steps rather than assuming a tap, scroll or expanded view is available. A truncated note is not automatically unusable, but the full instruction must be accessible quickly enough for your workflow.
Have a cook read the long bowl instruction aloud from the normal viewing distance. Then ask which item it belongs to and what action comes next. Repeat with the two similar bowls. If opening a detail view hides the item name or makes it unclear which ticket the cook is viewing, record that as a context problem even if the full text is technically visible.
Check how the layout behaves when a note spans several lines. Does it push the next item down in a way staff can follow? Can a cook distinguish the continuation of a note from a new item? If the system offers display settings, compare the settings you would actually use. Do not accept a demonstration that depends on enlarging every ticket so much that the team cannot manage its normal workload.
Fleksa’s KDS software describes displaying item names, quantities and modifiers. Ask to see how item notes and long instructions appear in the configuration you would use. Apply the same demonstration to any other system on your shortlist.
Follow the instruction to every responsible station
Visibility on one screen is not enough when more than one person handles an item. Map the sample bowl from preparation through final assembly. Decide which station needs to read the instruction, who must make the confirmation, and who checks the finished order. The answer depends on your kitchen’s responsibilities, not just on the number of screens.
For the hypothetical sesame-allergy bowl, suppose a prep cook handles ingredients and an assembly cook finishes the bowl. Both need the relevant instruction, and the lead needs a clear way to resolve the question before work starts. Ask the vendor to show what each person sees in the proposed setup. If a station receives only part of the information, ask whether the display or workflow can be configured to provide the missing context.
Do not assume that every screen receives the same detail or that a ticket can be moved between stations in the way you expect. Describe your handoff and ask for a demonstration. If you are also deciding which items go to which station, the guide to routing kitchen tickets covers that separate decision.
Use a simple pass rule: each responsible person can identify the correct item and read the complete instruction on the view they are expected to use, or there is a specific, dependable handoff that supplies it before they act. A verbal handoff may be part of the process, but name the person who gives it and the person who receives it. “Someone will tell them” is not a workable procedure.
After the simulated check, consider a supervised service pilot only if the proposed workflow passes. Brief the team on what to watch for and who can stop preparation when an instruction is unclear. A live pilot involves real orders; it is separate from the practice tickets and should follow your normal service controls.
Set a decision boundary and an escalation procedure
Before comparing quotes or committing to a setup, write down what must pass. For this example, accept the display only if cooks can match each modifier and note to the correct item, read the complete instruction, and get the information to every responsible person. The check should work on the intended screen layout under a realistic simulated ticket load.
Use three outcomes. Pass: the team completes the checks without guessing or missing an instruction. Rework: a demonstrated setting or a named handoff fixes the problem, and the team repeats the check successfully. Do not proceed with that workflow: an instruction remains cut off without a usable full view, its item association is unclear, or a responsible person cannot reliably receive it. A strong display elsewhere does not cancel out a failure on a safety-related note.
For any unclear safety-critical instruction, make the manual response explicit:
- Stop preparation of the affected item. Do not infer missing words or substitute an ingredient based on a partial note.
- Tell the shift lead which ticket and item are affected, and show the instruction as displayed.
- Have the lead check the complete order information and, if needed, obtain clarification through the restaurant’s normal process. Keep the item on hold until the lead communicates a clear decision.
- Tell each responsible station the confirmed instruction before preparation resumes. If it cannot be clarified, follow the restaurant’s procedure for handling the unresolved order rather than guessing.
This procedure is a backup, not permission to buy a display that routinely hides essential text. Count how many steps staff must take to resolve a simulated problem and ask whether those steps are practical during your busiest period. Also ask who can change display settings, how staff are trained, and what support is available if the screen does not show the expected detail.
Bring your sample tickets, screen requirements and pass rules to a vendor demonstration. To compare your workflow and current product fit with Fleksa, discuss your requirements and ask to see the same checks in your intended setup.
Frequently asked questions
What is the difference between a modifier and a kitchen note?
A modifier is typically a structured choice attached to an item, such as no tomato. A kitchen note is often free text describing an instruction. Ask how each enters your system and how cooks can distinguish them on the display.
Is a truncated note always a failed test?
Not necessarily. It can pass if the cook can quickly open the complete instruction, keep the correct item and ticket in context, and share it with the people who need it. If those conditions are not met, treat it as a failure or rework the workflow.
Should every station see every order note?
Not automatically. Each person responsible for carrying out or checking an instruction needs the relevant information. Map those responsibilities and demonstrate how the instruction reaches them before relying on the setup.
