KDS tokens and screen placement

A kitchen display is not just another screen. It becomes part of the pass: the place where a cook, expeditor, and runner coordinate what is being made, what is ready, and what needs attention. That makes two details unusually important. The screen must be physically easy to read under heat, noise, steam, and movement; and the route into that screen must be protected like an operational credential rather than treated as a public link.

Many setup problems come from solving only the hardware question. A large monitor mounted in the wrong line of sight still creates neck strain and missed tickets. A convenient URL left open on a shared device can create confused handoffs or unauthorised changes. Design the physical position, access model, and shift ritual together.

Treat access as an operating responsibility

Start by deciding who needs to see the kitchen display and who needs to change it. A cook may need to mark a ticket in progress; an expeditor may need to mark it ready; a manager may need administrative access; a runner may only need a clear view of what is ready. Give people the least access that allows their job to be done safely and efficiently.

Do not print a private access token on a QR label visible to guests, paste it into a shared group chat, or leave it displayed on a counter-facing tablet. If a kitchen URL, password, token, or device is shared beyond the intended team, replace or rotate it through the approved administration process. The exact technical steps depend on the system, but the operational rule is simple: access changes should be traceable, intentional, and reversible.

Access question	Practical decision	Shift lead check
Who marks preparation states?	Name the station or role, not “anyone nearby”	Can that person explain the status sequence?
Who can change configuration?	Limit to authorised managers or administrators	Is an old manager’s access removed?
Which device stays signed in?	Use a dedicated, secured kitchen device where possible	Is the device locked when unattended?
What happens when staff rotate?	Use a handoff, not a shared secret	Did the incoming lead confirm access?
How are issues reported?	Use one known escalation path	Does the team know whom to call?

Avoid using a credential as a substitute for a proper staffing conversation. If every person needs unrestricted access to keep a shift moving, the state model or role allocation may need attention. A good kitchen display rhythm at peak hours reduces the temptation to let everyone make every change.

Place the screen where work already happens

Walk the kitchen during a real or simulated busy service before mounting anything. Observe where tickets are read, where food is plated, where a runner receives a handoff, and where people must keep clear for safety. The best screen position is usually close enough to the station or pass to be read without a detour, but not so close that heat, grease, splashes, or a crowd make it unreliable.

Check the viewing angle for the shortest and tallest people who will use it. A screen placed too high forces staff to look up repeatedly; one too low encourages bending and can be blocked by prep containers. Glare from a window, pass lamp, or polished tile can make a perfectly good display unreadable at the exact time it matters. Test it during the lighting conditions of lunch and dinner rather than relying on a daytime installation visit.

Use readable text and adequate contrast, but do not try to solve urgency with flashing colours alone. Tickets should be understood by their order, status, and key modifiers. If a visual cue is important, pair it with plain text and a known action. This makes the screen more accessible to people with colour-vision differences and less mentally tiring during a rush.

Define the screen states before the first live shift

Every status on the display must mean something observable. “New” might mean the kitchen has not acknowledged the ticket. “In preparation” might mean a station has accepted it. “Ready” should mean food is at the agreed handoff point, not simply that someone hopes it is close. “Served” may need a floor or runner confirmation depending on your workflow.

Write the sequence beside the screen in short language. Do not create more states than the team can reliably maintain. A simple model is better than a detailed model that everyone bypasses. If an item is unavailable or an order needs clarification, decide how the kitchen flags it and who speaks to the guest or floor team. The screen should not become a silent repository for unresolved problems.

State	Required evidence	Next person to act
New	Ticket is visible and complete enough to begin	Assigned kitchen station
In preparation	Station has accepted the work	Station lead monitors completion
Needs clarification	A real question prevents safe preparation	Captain or order owner
Ready	Food is at the agreed handoff point	Runner or expeditor
Handed over	Runner has taken responsibility	Floor team confirms table delivery if needed

Run the sequence through a few ordinary cases: a new order, a modifier question, an item that sells out, and a partial ticket. If the team cannot agree on the next action, simplify the language before guest service begins.

Make device care part of opening and closing

Kitchen equipment needs an owner at both ends of the shift. During opening, check power, network connection, screen readability, access, and the current menu availability. During closing, clear or secure the device according to your policy, clean it with a method suitable for the hardware, and record any issue that the next team must know.

Keep a non-digital fallback. A device can lose power, a network can fail, or a display can become unreadable. The fallback should preserve the same order identifiers and priorities so the team does not create two competing queues. When the screen returns, reconcile deliberately: identify which tickets were completed, which remain open, and who is responsible for communicating any delay.

Opening check	Closing check
Screen powers on and is readable from the working position	Device is secured or signed out according to policy
Correct outlet and current menu are visible	Surface is cleaned safely and any damage is logged
Access is limited to the intended team	Unresolved tickets and outages are handed over
State definitions are visible to new staff	Temporary notes are recorded in the approved place
Fallback material is available	Access changes or incidents are reported

Review after the first busy services

Do not judge a KDS setup from a quiet afternoon. After two or three peak services, ask cooks, runners, and captains where they lost time or information. Look for repeated physical moves: walking across a station to read a screen, calling out a ticket that is already marked ready, or turning a device toward the pass because the original position is hidden. Small adjustments in placement or state language can remove a surprising amount of friction.

• Confirm access belongs only to current, authorised roles.
• Test screen readability in heat, steam, and actual service lighting.
• Keep guest-facing spaces clear of private operational links and tokens.
• Use a short, shared state sequence with named next actions.
• Provide a single method to flag a clarification or stock issue.
• Practise a fallback and reconciliation before an outage forces it.
• Review the setup with people doing the work, not only installers.
• Record changes so the next outlet or shift does not repeat the same mistake.

The aim is a screen that feels almost invisible: staff can read it where they work, act on it with confidence, and hand it over safely. That is a better outcome than a flashy display that creates a new source of uncertainty.