Kitchen display setup guide: screens, stations, and ticket language

A kitchen display system should make the next kitchen decision easier: which ticket belongs to which station, what is waiting, what has changed, and what can move to the pass. It does not solve a kitchen’s workflow by itself. If station ownership, ticket language, and handoff rules are unclear before the screen is switched on, the display may simply make the confusion more visible.

Treat setup as an operational design exercise. Involve the kitchen lead, floor lead, cashier or order owner, and the person responsible for the technical configuration. Walk through a normal service as well as an unavailable item, a modifier, a merged table, a takeaway order, and a network interruption. The right setup is the one the team can explain under pressure.

Map the real stations and handoffs

Begin with the food journey, not with the device layout. List the stations that receive work, the prep that happens before service, the point where components come together, and the pass where a completed order is checked. Some kitchens need a separate beverage or dessert station; others work better with one combined view. Avoid copying another restaurant’s configuration without testing your own menu and staff roles.

Draw arrows for each handoff. An order may move from a server or QR flow to a cashier, then to a grill station, then to the pass, then to a runner. Mark where a ticket can be accepted, held, bumped, recalled, or escalated. Every state should have a shared meaning. “Done” should not mean “I saw it” for one person and “ready for the guest” for another.

Workflow element	Question to answer	Practical owner
Station	Who prepares this work?	Kitchen lead
Ticket route	How does an item reach the station?	System and operations owner
Modifier	Where does the required note appear?	Menu and kitchen owner
Pass	Who confirms a complete order?	Expo or shift lead
Exception	Who resolves a missing or unclear ticket?	Named escalation lead

The buyer questions in how to choose a kitchen display system are useful before selecting a platform; this guide focuses on the operational setup after that decision.

Define ticket language before configuring rules

Tickets need consistent, human-readable language. Use the dish names the kitchen and floor already recognise. Keep modifiers short, specific, and positioned where the relevant station will see them. Avoid unexplained abbreviations created during configuration; a new staff member should not need to decode a private shorthand during a rush.

Agree on what the system should show for item availability, table or order reference, course timing, takeaway context, and guest questions that require an escalation. If an ingredient or dietary concern needs a kitchen lead response, do not rely on a colour or tiny note alone. Build a visible process around it, as described in allergen communication for restaurant menus.

Create a short ticket glossary and place it where the team can use it. Update it whenever a dish, modifier, or station changes. This is not bureaucracy; it prevents the display from becoming a different language from the menu.

Place screens for the work, not for appearance

Screen placement affects whether people can see and use a ticket while working safely. Check viewing angle, glare, heat, steam, splash risk, cable routing, cleaning access, and whether a user can reach controls without blocking a preparation area. The best screen position may differ by station. Do not mount a display where a cook must turn away from the food repeatedly to read it.

Choose a readable density. If too many tickets appear at once, the team may miss priority; if too little context appears, staff must tap through several screens for a basic order. Test type size and contrast under the actual kitchen lighting. Make sure alerts are useful but not so frequent that they become background noise.

Plan for ordinary disruptions. A backup power, paper, device, or verbal fallback may be needed depending on the service. Write down who switches to it, how orders are reconciled when the display returns, and how the floor is informed. The team should not discover the fallback only after several tickets vanish.

Run a service simulation before go-live

Use test orders that represent real complexity: one ordinary table, a large party, a modifier, an unavailable item, two courses, takeaway, and a request that must be clarified. Watch the ticket from entry to pass. Ask each station to describe what it sees and the action it takes. If two people interpret the same state differently, revise the rule before launch.

Run the same test with the floor team. A server needs to know when to tell a guest that an order has reached the kitchen, when to check the pass, and how to handle a missing ticket. The service flow in how to reduce restaurant order errors can help connect the screen to the guest conversation.

Use this KDS setup checklist

• Each real station, pass, and handoff has a named owner and screen route.
• Ticket states have one shared operational meaning.
• Dish names and modifiers match the current menu and are readable at the relevant station.
• Screen placement has been checked for glare, heat, reach, cleaning, and safe movement.
• Alerts, colours, and priority signals are understandable without relying on colour alone.
• The team has rehearsed ordinary orders, exceptions, and an offline or device fallback.
• A short ticket glossary and configuration owner are available for future changes.

A kitchen display works when it makes the kitchen’s existing coordination clearer. Start with the people and handoffs, then configure the screen to support the work they actually do.