A table of four sits down at 13:10. Menus arrive at 13:14, the order is taken at 13:21, the bill lands at 14:05 — six minutes after they asked for it.
Nothing in that sequence is anybody's fault. It is what three separate waits cost at peak. Table ordering by QR removes two of them, and whether that turns into money depends on the kitchen and the floor, not on the code.
Where the time saving comes from
An order from a phone removes the first two of those three waits. The guest sits down, scans, chooses at their own pace and sends the order straight to the kitchen. The server appears with food, not with a question.
The practical effect: table turnover improves by a dozen or so minutes with the same team. At 40 covers and two lunch sittings, that is room for a dozen more guests a day.
What changes in the server's role
This is the most common misunderstanding: the system does not replace service, it moves it to where it has value.
What disappears: carrying menus, taking orders item by item, explaining what is in a dish, running for the bill — 4 tasks nobody earns money on.
What stays and becomes more important: the welcome, the recommendation, reacting to what is happening at the table, selling the dessert and the second glass. Those are the tasks where a person earns more than they cost.
Teams that roll this out without a conversation get resistance — servers correctly read the change as a hint at cuts. It is worth saying outright that the point is serving more tables with the same headcount, not a smaller headcount.
What has to be ready in the kitchen
This is where rollouts most often fail — more often than on the code itself. Orders from phones arrive differently distributed in time: not in waves when a server works a section, but singly and unevenly.
Four things have to be settled:
- where the order appears — a printer, a kitchen screen or a tablet;
- who confirms receipt, and within what time;
- what happens when an item runs out mid-service;
- how additional orders from the same table are linked.
The last point is the most practical: a table orders 3 times over an evening, and the kitchen has to understand that this is one booking, not three independent ones.
When it will not work
Honestly — there are setups where table ordering gets in the way:
- fine dining, where the conversation with the server is part of the experience;
- venues without signal — basements, thick-walled buildings, places with no Wi-Fi;
- very short visits at the bar, where the order takes 10 seconds anyway;
- a large share of older guests, for whom a phone at the table is a barrier.
In the first three cases a code with the menu alone (no ordering) still makes sense. We drew that line in QR menu or printed.
Payment: a separate decision
Ordering and paying are two different things, and they do not have to be rolled out together.
The cautious variant: the guest orders from a phone and pays as before — with a server or at the bar. That removes 2 of the 3 waits and needs no changes to accounting or the till.
The full variant: online payment at the point of ordering. The third wait disappears, along with the "the table left without paying" problem, but tips, bill corrections and refunds have to be thought through.
Start with the cautious one. Add the full one once the team has settled.
How to launch it in a week
- Decide where the kitchen sees orders — the one decision you cannot postpone.
- Print the codes and place them by the rules in QR code on the table.
- Trial it on one section of the room for three days before switching everything on.
- Tell the team what changes — not just how to tap.
- Measure turnover before and after. Without that number you cannot judge whether it worked.
How it looks on the system side is on the online ordering page.
Frequently asked questions
Does table ordering replace servers?
No. Carrying menus and taking orders disappear; recommendation, reacting at the table and upselling stay — which is what the venue earns on.
Does the guest have to pay online?
No. Ordering and paying can be separated: the guest orders from a phone and pays a server as before. That is the safest way to start.
What if a dish runs out after the order is placed?
The item is switched off in the panel and disappears from the menu the same minute. Orders placed earlier are handled by a server — the same as with a paper menu.
Does it work with a full room?
It works as long as there is signal. A crowd absorbs signal, which is why the test has to be run with a full room, not in an empty venue in the morning.
