Kitchen ticket system for a bar or restaurant: what to look for
How to judge a system that turns an order rung in at the register into a ticket at the station that makes it.
What the system is actually doing
Most places already have the parts: a register at the front, a bar, a kitchen, and staff who know the menu. What a ticket system adds is the rule that joins them. An order rung in at the register becomes a ticket at the station that makes it, printed there, without anybody carrying a docket through a doorway or calling an order down a rail. One order with a drink and a plate becomes a ticket at the bar and a ticket in the kitchen, each showing only the part that station is responsible for.
That sounds small until you count what it replaces: handwritten dockets, orders rung in twice because nobody was sure the first one landed, and food coming up with no drink to go with it. Choosing a system is mostly choosing how reliably that one rule holds when the room is full and nobody has a spare hand.
What to look for
Orders start at the register, with the card payment handled in the same motion. Staff ring the order, take the card, and the tickets print - not three separate pieces of software and a reconciliation at the end of the night.
Every item on the menu is assigned to a station, and that assignment lives in the menu rather than in the head of whoever happens to be working. When an item moves from the bar to the kitchen, you change it in one place.
The order is recorded somewhere durable the moment it is paid for, before anything tries to print it, and a ticket that could not print is retried on its own when the station is ready again. A system that treats the print attempt as the record will lose orders the first time a printer is busy.
Each ticket is identified so it cannot print twice. A retry, a re-send and a station reconnecting should all produce the same single ticket, not three.
The paper is readable at arm's length across a counter: the station's name, the order's name, each item large, and modifiers sitting directly under the item they belong to rather than in a block at the bottom.
Ordinary thermal printers of a standard you can buy again. A station printer is a consumable part of the room - it gets knocked, soaked and unplugged - and a replacement should be a trip to a shelf, not a call to a vendor.
Somebody is told, by name and while service is still happening, when a station stops printing. A silent counter is the failure that costs you orders, and no dashboard in an office will catch it.
If you also want guests ordering from a code at a table or counter, it should produce exactly the same ticket at the same station as the register does. That is an option on top of how you already work, not a second system running alongside the first.
The questions that tell you the most
Three questions tell you more than a demonstration will. Ask where an order lives between the moment it is paid for and the moment it prints - if the answer is a screen, or an app's memory, you have found the weak point. Ask what staff do when a station's printer is off, and listen for whether the answer involves anybody retyping anything. And ask who gets told, and how, when a counter goes quiet mid-service. Someone who has run real rooms answers all three flatly; someone who has not will steer you back to the menu editor.
Proving it before you commit
Set the hardware up on a bench and put it through the four things that go wrong. Ring a mixed order and check each station gets only its own items. Pull the paper out of one printer mid-order, finish the order, then reload and watch the ticket arrive by itself. Send the same order twice and confirm you get one ticket at each station. Switch a station off entirely and see whether anybody is actually told. A system that passes those on a quiet afternoon is one that will hold when the room is full, and no demonstration tells you nearly as much.