A restaurant’s kitchen rhythm is set by the KDS. When the integration breaks, the whole service slows - and not because the tech is dead. The till is taking orders, the card terminal is approving payments, the floor is humming. But one station is printing tickets, another isn’t, the grill screen has frozen on a check from twenty minutes ago, and the expeditor has no idea what’s actually been fired. Tables wait. Mains land before starters. The head chef is writing courses on a paper pad like it’s 2004.

That is what an integration failure looks like in a kitchen. It is rarely a clean outage. It is almost always a partial one - and partial outages are worse, because nobody is sure whether to keep going or stop and reset.

This post is for ops directors, GMs and head chefs who have lived through that and want to understand what is happening underneath. We will walk the EPOS-to-kitchen pipeline, the four common architecture patterns, the failure modes we see most often, and how to design and support a kitchen so the pipeline holds when service is at full tilt.

The EPOS-to-Kitchen Pipeline, Step by Step

Before you can fix the integration, you have to know what is actually moving through it. A typical order on a modern EPOS estate goes through roughly seven steps:

  1. Table is opened on the EPOS - covers, server, time stamp recorded
  2. Items are entered against the check, with modifiers and course tags
  3. Items are routed by the EPOS based on menu configuration - each item is tagged for a station (grill, garde manger, pastry, bar, pizza, pass) and a delivery method (printer, screen, both)
  4. The order is fired - either automatically on send, or held against a course and fired by the expeditor when starters clear
  5. The KDS or printer receives the ticket over the kitchen network
  6. The chef cooks and bumps - bumping the item on the screen marks it as ready and removes it from the active queue
  7. The expeditor clears the check, the floor runs the food, the table moves on

Every one of those steps is a join between two systems. Step 3 alone is doing menu logic, network routing, hardware addressing and protocol translation. Get the routing wrong on a single modifier - say, a fries upgrade tagged to the grill instead of the fryer - and an entire station starts working from a check that doesn’t match what the floor sold.

This is why “the printer is broken” is almost never the actual problem. The actual problem is usually upstream.

Four Architecture Patterns You Will Find in the Wild

Most kitchens we walk into use one of four patterns. Knowing which one you’re running matters, because the failure modes are different.

1. Pure print. Every station has a thermal printer. The EPOS prints tickets directly. No screens. This is what most independents still run, and it is genuinely robust until it isn’t - printers jam, run out of paper mid-rush, and there is no audit trail. When a ticket is lost, it is just gone.

2. KDS only. Every station has a screen. No tickets anywhere. Common in newer fast-casual concepts. Clean, auditable, easy to manage menus across sites. But the moment the kitchen network blinks, every station goes dark at the same time. There is no fallback unless you have built one.

3. Hybrid print plus KDS. Screens at the cooking stations, a printer at the pass or expeditor station as the system of record. This is what most well-run mid-market restaurants do, and we generally recommend it. The print stream is a redundant copy. If the screens die, the expeditor can run service off the printer until you sort it out.

4. Cloud KDS. The KDS is a SaaS app talking to the EPOS over the internet. Lighter hardware, easier multi-site deployments, but you have just made your kitchen depend on your WAN. If the broadband flaps, the kitchen flaps. We have strong opinions on this one - see our managed network service - and they all start with “you need a second circuit”.

There is no single right answer. There is a right answer for your menu, your throughput, your site count and your tolerance for downtime. What matters is that you have made the choice deliberately, not inherited it from whichever installer wired the kitchen in 2017.

The Integration Failures We See Most Often

After enough kitchens, the failure modes start to repeat. The big ones, in roughly the order we encounter them:

  • Station routing misconfiguration. Someone added a new dish to the menu and forgot to tag the station. It prints nowhere. Or it prints everywhere. Both happen weekly across the estates we look after.
  • Printer dropouts. Paper out, ribbon failure on impact printers, network drop, firmware bugs that brick the queue until a power cycle. Epson TM-T88 and TM-m30 series are workhorses but they are not immortal.
  • Dead ethernet switch in the kitchen. Heat, grease, a cable knocked loose by a porter cleaning behind the line. The switch in the kitchen is the single most abused piece of network kit in the building, and it is almost always the cheapest unmanaged box on site.
  • DHCP and IP address issues. A printer comes back from a power cycle with a different IP, the EPOS is still trying to talk to the old one, tickets queue silently. Static reservations on the DHCP server fix this - almost nobody sets them up.
  • Incorrect item tagging on the menu. Modifiers in particular. “No cheese” goes to the grill but “extra cheese” goes nowhere because it was added as a price modifier without a station tag.
  • Stuck print queues. A single malformed ticket can wedge the queue. Every subsequent ticket sits behind it, the kitchen has no idea, and the floor is looking at a pass with no food on it.
  • KDS bump station out of sync. The screen and the controller disagree about what has been bumped. Items reappear. Chefs lose trust in the system within one service and stop using it.

None of these are exotic. All of them are preventable with monitoring, configuration discipline and decent hardware standards.

Designing the Kitchen for Resilience

If you are specifying a new kitchen or remediating an existing one, the principles are not complicated. They are just rarely followed.

  • Wire it. Wi-Fi has no place in the back of a kitchen. Run cable to every printer, every KDS controller, every till. Wireless is for the floor and the office.
  • Standardise the printer estate. Pick one brand and one or two models across the group - Epson TM or Star Micronics are the safe choices. Spare parts, firmware, paper rolls and replacement units all become interchangeable. A multi-site GM should be able to pull a spare from one venue and drop it into another in fifteen minutes.
  • Hold spares on site. At minimum: one spare printer per critical station, a spare network switch, a spare KDS bump bar or controller depending on your hardware. Cold spares cost less than one lost Saturday.
  • Redundancy on critical stations. Pass and grill should print and screen, not one or the other. The cost of a second printer is trivial against the cost of a service running blind.
  • Monitor the kitchen network. Every printer, switch and KDS controller should be on a monitoring system that pages someone when it goes offline - not when a chef notices.
  • UPS the network rack. A two-second power blip should not require a kitchen reboot.
  • Document the routing. A spreadsheet of which items go to which stations, kept current, owned by one person. When the menu changes, the routing changes with it.

What Your IT Provider Should Actually Know

Most generic MSPs are not equipped to support a kitchen. They can manage your laptops and your Microsoft 365 tenancy, but if you ask them about Epson TM ESC/POS commands or how a Zonal KDS controller pulls its menu, you get a blank stare. That gap is where most of the pain lives.

The team supporting your kitchen needs to know, on day one, the difference between an Epson TM-T88VI and a TM-m30II, how Star TSP100 series handles cutter errors, what the common KDS controllers look like for the EPOS you run, how your menu structure flows from head office down to site, and what your kitchen network actually looks like when you draw it on a whiteboard. They need to be monitoring it. They need to have a relationship with your EPOS vendor so that “is this an EPOS problem or a network problem” can be answered in minutes, not days.

This is the gap we built our hospitality IT support practice to fill. It is also why we keep a deep bench of engineers who have actually stood in a kitchen at 8pm on a Saturday and fixed something with the head chef looking over their shoulder. If you run sites in Soho or anywhere across central London, that is the standard you should be holding your provider to.

When to Move From Print to KDS - and When Not To

A reasonable question we get asked a lot: “should we move our print kitchen to a KDS?” The honest answer is, it depends on three things.

Move to KDS or hybrid when you have high ticket volume and printer management is consuming staff time, when you want auditability and timing data - bump times, average cook times per dish, stations under pressure - to actually run the kitchen on data, or when you are operating multiple sites and need consistency across them.

Stay on print when your menu is short, your volume is moderate, your team is comfortable with paper, and the cost of retraining and rewiring will not pay back. There is no shame in a print kitchen that works. There is plenty of shame in a half-installed KDS that nobody trusts.

If you are unsure, hybrid is almost always the right interim step. Put screens on the cooking stations, keep a printer at the pass, and run both for a service or two. The kitchen will tell you very quickly which one they prefer.

The Bottom Line

KDS, EPOS and printers are not three separate systems. They are one system with three faces. Treating them as separate is how you end up with three vendors blaming each other while the floor is plating starters with no mains in sight.

If your last service was slowed by a kitchen integration problem and you are not sure who to call about it, that is the conversation we have most weeks. Talk to us about hospitality IT support and we will walk your kitchen with you.