How to Set Up a Kitchen Display System (KDS) That Actually Speeds Up Service

A kitchen display system replaces paper tickets with screens. That is the one-sentence version, and it is almost useless. The useful version is this: a kitchen display system (KDS) is a screen-based order routing layer that sits between your POS and your line, organizes tickets by station, tracks how long each one has been working, and tells the expediter when every component of a table's order is ready to leave the pass. Done right, it raises order accuracy 20-40%, drops average ticket time 15-25%, and lifts peak throughput 10-20%. Done wrong, it is just an expensive paper printer that also crashes.

The difference between done right and done wrong is not the screens. It is the routing rules, the station map, the expedite protocol, and the dry-run week before you go live. This post walks through the setup sequence operators actually use — not the marketing version, the kitchen-floor version. By the end you should be able to map your stations, route your menu, and avoid the four or five mistakes that cause new KDS deployments to get unplugged within ninety days.

Paper tickets have run kitchens for a hundred years and they have specific, named failure modes. Tickets get lost when they fall behind the line. Handwriting is illegible when the printer is low on ribbon and the expediter is in the weeds. Modifiers get missed because they are crammed into a corner of the chit in 6-point type. Online orders arrive on a separate printer at a separate station that no one is watching. And nobody can answer the question "how long has table 14's food been working?" because nobody is timing it.

A KDS makes those failures expensive to ignore. Each ticket fires to the correct station screen the moment the server submits it. Every modifier renders at full size in a contrasting color. Online orders flow into the same queue as dine-in. A timer runs on every ticket, color-coded so the manager can see the slowest tickets from across the kitchen without asking. And when a cook bumps a finished item, the next station — usually expedite — sees it immediately.

That last part is the one that turns a KDS from a nice-to-have into a real lever. The expedite screen is where a kitchen stops behaving like five independent stations and starts behaving like a single system.

Numbers in the KDS marketing space tend to be optimistic. Here are ranges that we have seen hold up consistently across operators of 50-300 seats with a working expedite station and at least one week of training. Your mileage will vary with menu complexity, staff tenure, and how disciplined you are about the dry run.

The accuracy and comp-rate numbers tend to be the most overlooked. A restaurant doing $80,000 a month in revenue and dropping its comp rate from 2% to 1% just recovered $800 a month in margin — usually more than the KDS hardware costs in any reasonable amortization. The throughput gain on Friday and Saturday nights is gravy on top.

Before you buy a screen, draw your stations on paper. Not the stations you wish you had. The stations that exist in your kitchen right now, with the cooks who work them and the dishes they produce.

The most common five-station map for full-service restaurants:

Quick-service and fast-casual concepts often collapse this into three: assembly line, fryer, expedite. A bakery or coffee shop might run two: bar and pastry. The shape matters less than the discipline of writing it down. The most common rollout mistake is over-segmenting — eight stations on the floor, eight screens, eight queues, and now the expediter is the bottleneck because nothing is in sync.

If you are not sure whether two functions should share a station or split, share by default. You can split later if the volume warrants it. Splitting prematurely creates handoff overhead that did not exist before.

This is the part that decides whether your KDS works. Every menu item needs to know where it goes. Most items have one home: a Caesar salad goes to cold prep, a ribeye goes to hot line. But a meaningful subset have two stations — a salad-and-entrée combo, a fried-app-with-dipping-sauce, a burger with both grill (patty) and fryer (fries) components.

Two-station items are where coordination indicators earn their keep. A modern KDS shows the item on both station screens with a visual marker (a number, a color band, or both) that says "this is part of ticket 47, the other half is on grill." When one station bumps their half, the other station sees a state change. Expedite then sees the ticket consolidate when both halves are bumped.

The tagging exercise is tedious but one-time. For a 60-item menu, expect to spend 2-4 hours mapping items to stations the first time. Plan to revisit it whenever you launch a new menu — about every quarter for most full-service operations.

"Bumping" a ticket means the station has finished their part and is sending the ticket to the next stage. The default bump flow for a five-station kitchen looks like this:

Two decisions you will need to make explicitly: do you allow partial bumps (sending one item to expedite before the rest of the table is ready, useful for apps), and do you allow re-fires (an item that has to be remade because of a comp or a misfire). Most kitchens want both. The KDS configuration should support partial bumps by item and a clean re-fire workflow that does not disrupt timing on the rest of the table.

Every KDS shows elapsed time per ticket. The colors usually go green, yellow, red. The question is when each color triggers. The defaults most operators land on, after some tuning:

These are starting points, not laws. A steakhouse with 35-minute prep times will set yellow at 25 and red at 35. A QSR will set yellow at 4 and red at 7. The right thresholds are the ones where yellow tickets are unusual but not rare, and red tickets are genuinely actionable. If half your tickets are red by 6pm Saturday, the thresholds are too tight and the cooks will start ignoring them — which defeats the purpose. If nothing ever goes yellow, they are too loose and you are not catching the slow tickets in time to recover.

Hardware matters less than people think, but a few decisions are worth getting right the first time.

Screens. Most kitchen screens are 15-22 inches, with 19-22 being typical for line stations and 15 inches sometimes used for cold prep or smaller bar setups. Look for splash-rated displays (IP54 at minimum) for any screen near the line — kitchen environments destroy consumer-grade monitors quickly. Brands operators use commonly include Elo and Lilliput in the commercial-display space, plus some POS vendors ship their own KDS-certified hardware.

Bump devices. You have three options. Touchscreens (simplest, but cooks with gloves or oily hands struggle), bump bars (physical button strips that map to ticket positions on screen — fastest and most durable for high-volume lines), or mouse/keyboard (rare in real kitchens, mostly for office or backup use). Most full-service kitchens use bump bars on the line and touchscreens at expedite, which suits the workflow well.

Mounting. Screens go where the cook can see them without turning their head from the cook surface. Eye level when standing at the station. Not above the salamander where heat will cook the LCD, not facing a window that will glare it out at lunch. Mount with vibration-damping arms for stations next to heavy equipment.

Network. Wire it if you can. Wi-Fi works, until the night it doesn't, which will be a Saturday. A KDS that loses connection to the POS is a kitchen with no orders. Most operators run a dedicated VLAN for kitchen hardware.

A KDS by itself is useful. A KDS connected to the rest of your restaurant systems is a different animal.

POS. This is the non-negotiable connection. Your POS is where orders originate (dine-in via server, online via integrations) and where the KDS gets its routing rules. Most modern restaurant POS platforms — Toast, Square for Restaurants, Clover, Spoton, and others including Deelo POS — include KDS modules or supported partner integrations. The right choice depends on what your POS already supports and what your menu complexity requires; the integration depth varies meaningfully across vendors.

Online order platforms. DoorDash, Uber Eats, Grubhub, ChowNow, your own website. Every one of these should flow into the same KDS queue as your dine-in orders, ideally with a visual indicator that the ticket is for delivery or pickup. The single biggest workflow win when restaurants move from paper to KDS is that online orders stop being a parallel kitchen — they become the same kitchen with a tagged subset of tickets.

Reservation system. A reservation system that knows about dietary flags (gluten-free, allergies, VIP status) should pass those flags to the KDS when the table orders. Deelo Bookings handles dietary flags on the reservation record; when a tagged guest orders, the KDS shows the allergy callout prominently on the ticket. This is the kind of detail that prevents a comp at best and an ambulance at worst.

CRM / loyalty. A guest with a VIP tag in CRM should show up on the KDS ticket. Not because the cook plates differently, but because the expediter knows to walk it out personally instead of handing it to a runner. Small touch, real value for high-value guests.

This is the step nobody wants to do and the step that decides whether the rollout sticks.

For at least five service days — ideally including a weekend — run the KDS and paper tickets in parallel. Cooks bump tickets on the KDS as they finish, AND the paper ticket continues to drive the actual production. The point is to surface routing mistakes (an item tagged for cold prep that actually comes off the grill), training gaps (a cook who doesn't know how to bump a partial), and integration bugs (online orders that are duplicating because two integrations are firing the same order).

At the end of the dry run, hold a 30-minute kitchen meeting. Walk through every issue. Fix routing. Retrain. Then pull the paper tickets and go live.

Restaurants that skip this step usually unplug their KDS within a month. The system gets blamed for what was actually a configuration problem that a dry run would have caught.

Deelo's restaurant stack runs three apps off one customer and order database: POS handles the front-of-house order entry and the KDS routing, Bookings holds reservations and dietary flags that ride through to the kitchen ticket, and CRM owns guest loyalty and VIP tags that surface on the order. Because all three share the same data layer, there is nothing to integrate between them — a reservation made in Bookings with a gluten-free flag will surface that flag on the KDS ticket the moment the table orders, without a Zap or a webhook in between.

The practical effect is that the KDS isn't a standalone box bolted onto the kitchen. It is a view on the same order data the server entered, the same guest data the host took at the door, and the same loyalty data the marketing manager is using to send retention emails next week. A VIP regular's birthday note shows up on the expedite screen because the same record drives the email campaign.

If you are running multiple disconnected systems today — a separate POS, a separate reservation tool, a separate loyalty product — the integration tax between them is usually the thing that breaks a KDS rollout, not the KDS itself.

A KDS is not a magic ticket printer. It is a workflow tool that exposes how your kitchen actually runs and gives you the data to improve it. The restaurants where it works best are the ones who treat the rollout as a kitchen-operations project, not an IT project — where the chef and the GM are in the routing-rule conversation, where the expediter gets two full shifts of training, where the dry run is taken seriously, and where the ticket-time report gets reviewed every week for the first quarter. Do those things and a KDS earns back its hardware cost in saved comps and recovered throughput within a single busy quarter. Skip them and the screens get unplugged by month three.