Watch an order travel through a busy restaurant. A diner says it to a server. The server writes it down, or doesn't. It's carried across the room, typed into a till or shouted at a pass, printed on a slip, clipped to a rail, and read by somebody under time pressure with four other slips in front of them.
Six handoffs, at least two of them through human memory, on every table, all night. Most of the errors your kitchen makes are not cooking errors.
QR table ordering removes the first three handoffs. That's the whole idea, and everything worth saying about it follows from how well the remaining ones are handled.
What measurably changes
The order arrives when the table is ready, not when a server is
The gap between a table deciding and a table ordering is dead time you're paying rent on. On a full Saturday it can run ten minutes, because the decision happens when it happens and the server arrives when they can. Self-ordering collapses that to zero, and the compounding effect over a service is real: tickets start earlier, the kitchen's load spreads out instead of arriving in waves when servers finish their rounds.
Nobody transcribes anything
No handwriting to read, no "was that two or three", no modifier lost between the table and the till. The diner tapped the item, so the item is what the kitchen sees. This is the change that staff notice first and the one that never gets mentioned in the sales pitch, because it's hard to put a number on an argument that didn't happen.
The second round stops needing a hand in the air
The largest revenue effect isn't the first order, it's the second. A diner who wants another beer at 21:40 has to catch someone's eye, and on a busy night a meaningful share of them simply don't bother. When ordering is a tap, the second and third rounds happen. Venues with a drinks-heavy mix tend to see the difference here rather than anywhere else.
The order-taking trip was never the expensive part. The drink nobody managed to order was.
The group problem, and the shared tab
Here's where a lot of QR ordering falls over in practice, and it's worth checking before you buy anything.
Six people sit down. If each of them scans the code and orders separately, the kitchen gets six tickets for one table arriving over eleven minutes, the food comes out in six waves, and at the end there are six bills nobody can reconcile. That's worse than a server with a notepad, and it's the default behaviour of a surprising number of systems.
What you want is a shared session: one diner scans and opens the table, everyone else joins with a short code rather than scanning separately, and every item lands on one running order. The kitchen sees one ticket for the table. The bill is one total.
One scan
First diner opens the table. Everyone else joins with a four-digit code.
Everyone adds
Own phone, own choices, one running order for the table.
One ticket
The kitchen sees a table, not six strangers who happen to be sitting together.
One bill
A single total at the end, with the tax lines already right.
The join code matters more than it sounds: it's also what stops somebody at the next table adding to your order.
That last point is a genuine security question rather than a theoretical one. A table QR that anyone can scan from across the room, or from the pavement outside, is a way for a stranger to put food on somebody else's bill. The session has to be bound to the table and joinable only with a code the people actually sitting there can see.
The kitchen display, and what it's actually for
A screen in the kitchen is usually sold as a replacement for the ticket printer. That undersells it. A printed slip tells the kitchen what to cook. A display tells them what to cook and how long it has been waiting, which is the information that changes decisions during a rush.
The things worth having:
- Time on every ticket, counting up. The single most useful number in the kitchen, and the one paper cannot give you.
- Colour that changes at your thresholds. Amber at eight minutes, red at fifteen, set to your food rather than a default.
- Bump, and un-bump. Tickets get cleared by accident. Getting one back must not require an owner.
- Items added to an open table, marked as new. A second round landing on an existing ticket has to be visually obvious or it gets missed.
- Readable from where the chef actually stands. Two metres, steam, bad light, wet hands. Test it in the kitchen, not on a laptop in the office.
And the honest case for keeping the printer: it needs no training, it survives a flat battery, and a rail of paper can be reordered by hand in a way a screen sometimes can't. Run both for the first month or two. Removing the printer on day one is how a kitchen ends up hating the screen.
What happens when the wifi drops
This is the question to ask every vendor, and it's almost never answered on a pricing page.
A restaurant's connection goes down at 20:15 on a Saturday. With a system that queries a server for every screen, everything stops at once: no new orders, no bumping a ticket, no closing a bill. Staff stand around with tablets showing spinners while a full room waits, and the evening is reconstructed later from memory.
What you want instead is that the menu and the open orders live on the device, so the tablet already knows the prices and the state of every table. Staff carry on taking orders. Tickets can still be cleared. Writes queue locally and sync when the connection returns, and — this is the part that gets missed — the screen has to tell staff that work is queued rather than lost, or they redo it and you get two of everything when the connection comes back.
"If my internet dies at eight on a Saturday, can my staff take an order, bump a ticket and close a bill?" Not "is there an offline mode" — a menu that's cached while the ordering flow isn't leaves you with a beautiful, useless till. The answer you want names all three operations.
There's a related point about the diner's own signal. If your dining room has weak coverage, self-ordering will fail for the diner regardless of what your staff devices can do — and a phone that spins on a loading screen is worse than a printed menu. In a basement or a thick-walled building, the useful configuration is often staff taking orders on a tablet with the same system, keeping the ticket flow and the timings, without asking the diner's phone to do anything at all.
Where it genuinely doesn't fit
Being straight about this saves everybody a bad month.
- Rooms where service is the product. If the reason people book is that somebody talks them through the specials, replacing that conversation with a tap removes the thing they came for.
- Menus that need explaining. Unfamiliar ingredients, tasting formats, anything where the server's description is doing real selling.
- Older or mixed-age tables. Not a problem to solve so much as a fact to accommodate. A staff-facing ordering screen handles the table that would rather not, without anyone making a thing of it.
- Allergies. Never let a phone be the only channel. A structured note field is good; a member of staff confirming it at the table is not optional.
The version that works nearly everywhere is both: QR ordering for the tables that want it, a staff ordering screen for the ones that don't, and both feeding the same kitchen display so the timings and the bill work out identically either way.
Rolling it out without a bad Saturday
Nearly every disaster story is a rollout story rather than a software story.
- Start on your quietest night. Never a weekend, never an event.
- Get the menu right first. Every price, every modifier, every out-of-stock toggle. A wrong price is a public argument at the counter.
- Keep the printer running alongside for a month.
- Brief the floor on what changes. Their job becomes running food and reading the room. Say that out loud, because from the floor it can otherwise look like the first step to cutting shifts.
- Put the join code where the table can see it. Most group failures are a diner who scanned separately because nobody told them not to.
- Watch ticket times for two weeks. If they got worse, it's usually the kitchen display thresholds or the menu structure, not the concept.
And don't cut staff on the strength of it. The gain is that your existing people stop walking to take orders and start being present in the room — which is exactly what shows up in your reviews. Cutting the headcount at the same time converts a service improvement into a service cut, and the profile will say so within a fortnight.
RatingEcho runs table ordering on the same QR that already handles feedback and review invites, so there's one code on the table rather than three. Group tables join a shared session with a four-digit code onto one bill, staff can take orders on their own screen for tables that would rather not use a phone, and the kitchen display shows ticket age. Firestore persistence is on with the menu pinned in cache, so a connection drop mid-service leaves staff able to take orders, bump tickets and close bills — with a banner showing what's still queued, so nobody redoes work that already landed.