Walk into any kitchen at 8pm on a Friday and you can tell in about four seconds whether the pass is winning. Not from the noise. From whether anyone is looking at paper. In a kitchen running a kitchen display system, the grill cook glances up, reads two lines, and puts a hand on a pan. In a kitchen running a printer, somebody is holding a curled ticket at arm's length trying to work out whether table 14 wanted the salmon or the sea bass, and whether it was fired eleven minutes ago or four.
A KDS is a screen, or a set of screens, that replaces those tickets. Orders arrive from your restaurant POS system, land on the station that has to cook them, and disappear when somebody bumps them. That is the whole idea. Everything interesting about a KDS is in the details underneath: which screen an item lands on, what the screen decides is late, and what happens when the wifi drops during a 120-cover service.
What a kitchen display system actually is
Strip away the marketing and a KDS is four things working together. A routing engine that decides which items go where. Screens that show them. An input device that lets a cook clear a line without touching a greasy display. And a clock, running on every ticket, that nobody can argue with.
That last part is the one operators underestimate. Paper does not know what time it is. A ticket that has been sitting under the salamander for nine minutes looks exactly like one that printed forty seconds ago. A screen knows, and it will not let you forget: at your threshold it turns yellow, at the next one it turns red, and the number in the corner keeps counting whether or not anybody wants to look at it.
The other structural difference is that a KDS splits an order. A printer gives the whole check to whoever the printer belongs to. A screen gives the grill the two steaks and the fryer the fries, at the same moment, from the same order, without either cook reading past their own work. On a six-item table that is the difference between scanning a ticket and just cooking.
The parts you are actually buying
Vendors quote "a KDS" as if it were one object. It is not, and the pieces fail differently.
The screen. Anything from a $200 consumer tablet on a counter stand to a sealed 24 inch panel bolted above the pass. This is the part people shop hardest and, honestly, the part that matters least until it breaks.
The bump bar. A small keypad, usually six to twelve keys, mounted under the screen. A cook clears a ticket by hitting a key with the back of a knuckle. Touchscreens sound better in a demo and are worse in a kitchen: hands are wet, gloved, or covered in flour, and a touchscreen with a film of oil on it registers about two thirds of what you tell it. If a vendor will not sell you a bump bar, that tells you something about how many kitchens they have stood in.
The routing rules. Software, not hardware, and the actual product. More on this below, because this is where rollouts succeed or quietly fail.
The connection back to the till. Either the KDS is a module of your POS, in which case orders arrive natively, or it is a third-party system talking over an integration, in which case ask hard questions about what happens when that integration is down.
How an order gets from the till to the right screen
This is station routing, and it is the single concept that separates a KDS that helps from a KDS that annoys.
Every item on your menu gets tagged with a station. Ribeye goes to grill. Caesar goes to cold. Tiramisu goes to pastry, or to cold if you are a 40-seat bistro where pastry is a shelf in the walk-in and the same person does both. When an order lands, the system reads those tags and splits the order across screens, so each station sees only its own items, and the expo screen sees all of them.
Sounds simple. It is simple, right up until the edges, which are where every kitchen lives. A burger needs the patty from grill and the bun from the toaster and the fries from fry, and those three things have to land on the pass within about thirty seconds of each other or the fries are limp. A menu item can therefore route to more than one station, and the good systems let you set a different prep time per component so the screen fires the fries later than the patty.
Get the tags wrong and you get the classic failure: an item silently routed to a screen nobody reads, discovered twenty minutes later when the table asks where their food is. Before go-live, print your whole menu and write the station next to every single line. Not most lines. Every line. This is the tedious work that decides whether week one is calm.
What a good ticket looks like on screen
A ticket has about one second to be understood. Design for that.
The things that earn their space: the table or order number, big. The item and quantity, bigger. Modifiers directly under their item, indented, not floating at the bottom where they get missed. A timer. And the order type, because "3 x wings" for a table and "3 x wings" going into a delivery bag are two different jobs.
The things that do not: the server's name in 24 point, the full timestamp with seconds, your logo, the cover count, and the table's phone number. Every one of those is a real thing somebody has put on a real kitchen screen, and every one of them pushes the food further down.
Allergy and dietary flags deserve their own treatment. Not a modifier in the same grey as "no onions". A coloured band across the ticket, or a symbol that survives being glanced at from four feet away in steam. If your system cannot make an allergy note visually louder than a preference, that is a genuine safety problem, not a formatting preference. Our guide to allergen management goes further into how that should be handled end to end.
Timing: how the screen decides what is late
Every KDS has thresholds. Default is usually something like green under eight minutes, yellow eight to twelve, red past twelve. Those defaults are wrong for you, because they were set by somebody who has never cooked your menu.
The number that matters is not "how long has this ticket existed". It is "how long should this ticket have taken". A plate of oysters and a slow-braised short rib should not share a threshold. Systems that only offer one global timer force you to pick a number that makes the fast station look lazy and the slow station look fine, which is the opposite of useful.
What you want is a prep time per item, and a screen that works backwards from when the whole table needs to land. Set fries at 3 minutes and ribeye at 11, and the fries ticket should appear on the fry screen 8 minutes after the steak appears on grill. That is fire timing, and it is the feature that actually changes food quality rather than just changing where the ticket is displayed.
Choosing the screens: tablet, commercial panel, or rugged
Three tiers, and the right answer depends more on where the screen sits than on your budget.
Consumer tablets. Cheap, fine on a cold station or a coffee counter, and genuinely a reasonable choice for a food truck or a small bakery. They do not like heat, they do not like steam, and a dropped tablet is a dead tablet. Expect to replace them.
Commercial panels. A proper display in a sealed housing, typically 15 to 24 inches, designed to run 16 hours a day without the backlight giving up. This is the sensible default for most kitchens and where most operators should land.
Rugged, sealed units. Rated for water and dust, usually IP65 or better, with glass that survives an impact. You need these directly over a fryer, on a wash-down line, or anywhere a pressure hose gets used at close of service. They cost two to three times a commercial panel and in the wrong position that is money burned. In the right position they are the cheapest thing you will buy, because you only buy them once.
On size: 15 inches is enough for a station showing four or five tickets. The expo screen, which has to show everything, wants 21 inches or more. Reading distance decides this more than seniority does. Measure the distance from where the cook stands to where the screen will hang, and if it is more than about six feet, go up a size.
Mounting, heat, grease and the things that kill screens
The failure stories are boring and repetitive, which is good news, because it means they are avoidable.
Screens die from heat far more often than from impact. A display mounted eighteen inches above a flat top is sitting in rising air that can be 20 degrees hotter than the room, all night, every night. Mount high, mount away from the direct plume, and if you cannot, buy the rugged unit and stop arguing with physics.
Grease is the slower killer. It gets into vents, coats the fan, and the unit cooks itself over about eight months. Sealed, fanless units avoid this entirely, which is most of why they cost more.
Then the unglamorous things. Run the cabling before the screens arrive, not after. Put the screen where a cook can see it without stepping away from their station, because a screen that requires two paces to read will be ignored by the third week. And leave yourself a way to take one down and swap it in under five minutes, because at some point you will be doing exactly that at 7:40 on a Saturday.
What happens when the network drops
Ask this question first, in the demo, before anything about features. "Show me what the kitchen sees when the internet goes down."
There are three honest answers. The best: the KDS runs on the local network and keeps working, because the till and the screens are talking to each other over your own wifi and the cloud is only used for reporting. Orders keep flowing, data syncs later, nobody in the kitchen notices. The acceptable: the system holds a local cache, so tickets already sent stay on screen and new ones queue. The bad: the screens go blank, and your fallback is the printer you were told you could throw away.
Plenty of cloud-first systems are in that third category and will not say so unprompted. This is the most common unpleasant discovery in year one, and it always happens on a busy night, because that is when your network is carrying the most traffic.
Whatever the answer, keep one working printer. Not as a daily tool. As the thing you switch on during the twenty minutes a year when everything else is broken. The kitchens that rip out every printer on go-live day are the ones telling the story at the next industry night.
Setting it up: the prep-time data nobody wants to collect
The configuration itself takes an afternoon. The data that makes it useful takes a week, and this is the step people skip.
You need a realistic prep time for every menu item. Not the time it takes the head chef on a quiet Tuesday. The time it takes your weakest Saturday cook with six other tickets up. The gap between those two numbers is usually 30 to 50 percent, and if you configure the optimistic one, every screen in the building will be red by 7:30 and your team will learn within a fortnight that red means nothing.
The practical way to get the numbers: run two weeks with a timer and write down actuals for your top 30 items. That covers most of your volume. Estimate the tail, and correct it in month two using the data the system starts giving you.
Build the station map at the same time. Every item, its station or stations, its prep time, and whether it fires immediately or waits. Do it in a spreadsheet, get the head chef to argue with it, then load it. Loading it first and fixing it live is how you end up with a kitchen that distrusts the screens.
Training the line in the first week
Cooks adapt to a KDS quickly. Faster than front of house adapts to most things. But the first three services are genuinely worse than paper, and if nobody warns the team, you get the "this new system is slowing us down" narrative before it has had a chance.
Warn them. Then keep it to three rules: bump only when the food is on the pass, not when you start it. Recall is there when you bump by accident, so use it rather than shouting. And if the screen is wrong, tell a manager the same shift, because a routing error left alone for a week becomes a routing error the whole team has quietly worked around.
Go live on your quietest service. A Tuesday lunch, not a Friday dinner. Have whoever configured it standing in the kitchen for the first two services, doing nothing but watching and fixing. The second pair of eyes catches the item routed to the wrong screen in minute ten instead of day four.
Delivery and online orders on the same screen
This is where a KDS stops being a nice-to-have. A kitchen running dine-in plus two delivery platforms plus its own online ordering has four order sources, and on paper that is four printers and a human doing the merge in their head.
On a screen they are one queue, tagged by source, and that changes what is possible. You can hold a delivery order that would otherwise sit on the pass going cold while the rider is eight minutes out. You can see that 40 percent of your 7pm tickets are delivery and staff the line accordingly. You can stop the specific failure where a delivery order and a table order for the same dish get cooked twice because two people were reading two printers.
If you take a meaningful volume of third-party delivery, make platform integration a hard requirement rather than a later phase. A KDS that shows dine-in beautifully and needs a tablet farm for delivery has solved the easier half of your problem.
What the screen tells you that paper never did
Every bumped ticket is a timestamped record, and after a month you have something no printer ever gave you: a picture of where your kitchen actually slows down.
The reports worth opening are narrower than the ones vendors demo. Average ticket time by hour tells you when you are understaffed. Average by station tells you which station is the constraint, and it is almost never the one the team complains about. Longest tickets, filtered to the worst 5 percent, is the most useful report in the whole system, because your problem is rarely the average, it is the twelve tables a week that waited 25 minutes.
One warning. Ticket time data makes it tempting to manage people with a leaderboard. Resist it. The fastest way to corrupt the data is to make cooks feel judged by it, at which point they bump tickets early and your numbers become fiction while your food gets worse. Use it on the process, not on the person. The wider set of numbers worth tracking sits in our restaurant KPIs guide.
Where KDS rollouts go wrong
A short list, all of them seen more than once.
Too many screens. A 90-cover bistro does not need six stations. It needs hot, cold and expo, and the fourth screen just splits attention. Start with fewer screens than you think and add one when a specific station is genuinely drowning.
No expo screen. Individual stations see their own work, which means nobody sees the table. Somebody has to own "is this table complete", and that somebody needs a screen showing the whole order.
Thresholds left on default, so everything is red, so red means nothing.
The printer removed on day one, followed by a network outage in week two, followed by a kitchen that never fully trusts the system again.
And the quiet one: nobody owns the menu. Six months in, forty new items have been added by whoever was closest to the till, half of them untagged, and the routing you built so carefully has holes in it. Assign one person. Make menu changes go through them. Ten minutes a week prevents the slow rot.
What to test before you sign
Demos are designed to go well. Here is what to ask for instead, and it is reasonable to insist on seeing all of it on real hardware rather than a slide.
Pull the network cable mid-service and watch what the screens do. Send an order with a modifier, a substitution and an allergy note, and see whether all three are legible from where a cook would stand. Send a table where one item is on grill and one is on fry, and check the fire timing actually staggers them. Add a menu item, live, and time how long it takes to route correctly. Ask what a replacement screen costs and how fast one ships, because you will need that number eventually.
Then ask the pricing questions properly, because per-screen software fees have a way of turning a modest quote into a real monthly line. We have broken that down separately under what the screens cost, including the per-screen trap and what a five-year number actually looks like.
Start with the station map. Not the hardware, not the quote, the map. If you can write down every item on your menu and the screen it belongs on, you are most of the way to a rollout that works, and you will evaluate vendors on the thing that matters instead of on screen size.
Read next: KDS vs printers for whether to switch at all, kitchen brigade for how the stations you are routing to are organised, and back of house software for what else runs behind the pass.
