Kitchen display system (KDS)

Puts the live ticket queue on a screen at the point of production and records when each item was started and finished.

Orders arrive from the terminal as data rather than as paper. A display holds the open queue, and the barista bumps each item as it is completed. Because the order is data, the system knows when each item entered the queue and when it was bumped — and that timing, not the screen, is the actual product of a KDS. The second capability is routing: an item can be sent only to the lane that makes it, so the hot lane, the cold lane and the food pass each see their own work and nothing else. Paper cannot do that without printing the same ticket in several places, at which point the bar has several sources of truth and no way to tell which one is current.\n\nThe part that decides whether any of this survives contact with a bar is neither of those. A paper ticket sits in fixed peripheral vision and needs no hand: it is read at a glance and it is cleared by pulling it off a rail. A screen needs a look up and a deliberate touch with a hand that has just been holding a milk jug. Where the barista's eyes go, and what he must touch to clear a ticket, is the whole decision — everything else is a feature list.

• Start from where the barista's eyes already are, not from where there is a spare bracket. On a bar built around the movement triangle the workflow article describes, the ticket has to be readable from the working stance at the group head without turning the head away from the shot. A screen mounted where the installer found a cable run is worse than a paper rail mounted correctly, and no amount of software makes up for it.
• Decide what you actually want out of it before you price anything. If the honest answer is "the bar needs to see the orders", paper does that, cheaply and without a failure mode. A display earns its cost when you specifically want item-level timing, routing to lanes, and a record of what the bar actually produced hour by hour — and when you have somebody who will read that record and change something because of it.
• Match the display structure to the lane structure you actually run at peak, not the one on the drawing. If you split into hot, cold and blended lanes when it gets busy, routed per-lane screens are the entire point and a single shared screen will recreate the shouting you were trying to remove. If one person makes everything, a second screen is just a second place to look.
• Choose the bump method before the screen size, because it is the choice that decides adoption. Wet hands and a touchscreen is the failure that quietly kills a deployment: the team stops bumping in real time, starts clearing in batches, and every timing figure the system produces becomes worthless while still looking authoritative.
• Keep one source of truth. Running a paper rail and a screen together feels like prudence and is the reliable way to get a drink made twice or not at all. Pick one, remove the other, and make the changeover a deliberate day rather than a drift.
• A screen is a single point of failure that paper is not. Decide in advance what the bar does when the display is dark — whether the terminal can still print, who decides to switch, and how the team is told. A contingency invented during the outage is not a contingency.
• Do not deploy a display onto a menu structure you do not yet trust. The screen inherits the ticket exactly as the terminal composed it: if modifiers are free text, the screen shows free text, faster and in a worse font. Fix the menu tree first — that sequencing is the difference between a KDS that helps and one that gets blamed.
• Glare, viewing angle and mounting height are why installed screens end up ignored. Check the screen from the actual working stance, at the actual lighting level, with the room's real reflections in it, before the bracket is fixed. A screen the barista has to lean to read will be read late and eventually not at all.
• Sanitation is a selection criterion, not an afterthought. Whatever the barista touches to clear a ticket becomes a hand-contact surface between milk and cups, and a bezel with a lip in a splash zone is a cleaning job that never ends. This is one reason a bump bar often wins on a milk-heavy bar for reasons that have nothing to do with software.