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. The 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.

At the head of the lane it drives, inside the barista's existing field of view from the working stance. The workflow article's rule that one voice owns the queue still applies with a screen — the display does not replace the person calling sequence, it gives that person something accurate to call from. Position it so it competes with neither the group head nor the pass for the barista's attention, because those two already have first claim.

  • Buying a display to solve what is actually a menu-structure problem, and being disappointed when the screen shows the same unusable ticket faster.
  • Running paper and a screen together as insurance, which is the single most reliable way to produce a duplicate drink.
  • Mounting the screen where the installer found a cable route rather than where the barista's eyes already are.
  • Specifying a touchscreen for a milk-heavy bar without testing it with wet hands on a busy day.
  • Trusting ticket timings from a team that bumps in batches, and then making rota decisions on those numbers.
  • Deploying with no agreed plan for a dark screen, so the first outage becomes an improvisation in front of a full queue.
  • Treating the display as exempt from the sanitation round because it is electronic, when it is touched between milk and cups all shift.
  • A display and its controller are a continuous load in a position chosen for sightlines rather than for cabling, which is the whole difficulty — the cable route follows the mount, not the other way round. Circuit, protection and routing are for a licensed electrician to confirm and the local authority to govern; this site states no amperages.
  • Mount height and angle must let the ticket be read from the working stance without stepping back or leaning in, and the screen must not sit in the sightline between the barista and the pass.
  • Steam, milk aerosol and radiant heat are constant at bar height. An unsealed screen sited in the steam path fogs, then collects residue behind the bezel, then fails — and it fails slowly enough that the team works around it first.
  • Overhead or under-shelf mounting makes the bracket part of the bar's structure rather than an accessory, so it belongs in the joinery drawings and not in the equipment order.
  • Paper ticket rail
  • A physical rail carrying printed tickets in order, cleared by hand.
  • Nothing to learn, nothing to touch with a clean fingertip, and it never goes dark. It gives you no timing, no routing and no record — at close the data is a bin. For a single-barista bar this is often the correct answer, and saying so is not nostalgia.
  • Single shared screen
  • One display showing the whole bar's open queue.
  • The cheapest way into timing data. Every lane reads the same list and each person filters it mentally, which is precisely the cross-talk that slows a team more than the order volume does. It works well while one person makes everything and degrades as soon as the bar splits.
  • Per-lane routed screens
  • One display per production lane, each showing only the items routed to it.
  • This is what makes lane splitting hold together under volume — each person sees their own queue and stops arbitrating over a shared list. It costs more screens and, more importantly, a menu that has actually been mapped to lanes, which is work nobody budgets for.
  • Bump bar versus touchscreen
  • A physical row of keys that clears items, against clearing them by touching the screen itself.
  • A bump bar is operated by feel without looking and does not care about wet or milky hands. A touchscreen needs a look and a clean, dry fingertip. On a milk bar this single choice is the difference between a system the team uses in real time and one they clear in a batch afterwards, at which point the timing data is fiction.
  • Guest-facing status display
  • A screen showing guests which orders are in progress and which are ready.
  • Turns waiting into visible progress, which shortens perceived wait even when actual wait does not move. It is only honest if items are bumped as they genuinely complete — a bar that bumps in batches has built a screen that lies to its guests.
  • Items are bumped in a burst at the end of a rush rather than one at a time.
  • Bumping needs a clean fingertip or a reach the barista cannot make mid-drink, so the team defers it.
  • Every timing figure the system produces becomes fiction, and any guest-facing status display starts lying. The equipment still looks like it is working, which is what makes this the most expensive failure here.
  • The same drink is made twice, or a ticket is completed that nobody remembers making.
  • A paper rail and a screen running in parallel, so two records of the same queue drift apart.
  • Wasted milk and a remake, always at peak, plus the confidence loss that follows a drink handed to the wrong guest.
  • The barista turns away from the machine to read the queue.
  • The screen was mounted where the cable reached rather than where the eyes already were.
  • Seconds on every drink, and a shot that sits while the barista is looking elsewhere. It compounds exactly when it can least be afforded.
  • The screen fogs or the touch response becomes erratic during service.
  • Sited in the steam path, or an enclosure that traps milk aerosol behind the bezel.
  • The bar reverts to shouting mid-service, which is the state the display was bought to remove.
  • The display goes dark and the bar stops rather than switching to paper.
  • No agreed fallback, and often no printer left in place to fall back to.
  • Straight downtime, and a queue that has already been taken and paid for.

Related tools

Cleaning and care

Related articles

Equipment, workflow & commissioning

العربية