QR menu and table ordering: faster service, higher bills
Author:
Paweł Matusiak
·
The guest scans a code, sees a live menu, orders and adds extras without waiting for a waiter. The kitchen gets the ticket immediately. You stop reprinting 200 menus after every price change and pay no platform cut.
A paper menu is out of date a week after printing. At peak the waiter cannot reach the table. The guest wants a second round and cannot catch anyone. A QR menu with table ordering removes that bottleneck: the card is always current, the order hits the kitchen, and staff work the floor instead of writing tickets. In a bar or casual spot this can be full self-service. In a full-service restaurant it is a tool that shortens waiting — it does not fire the waiter.
This is for an owner who tracks average check and table turns, not for someone who wants to “look modern”. Below: what a venue loses without an e-menu, a day on a shift with codes on tables, which 2024–2026 numbers actually come back, when a PDF behind a QR is enough (almost never if you want orders), and how to roll out an app without stalling Friday lunch.
What a restaurant loses without an e-menu
Printing a menu is not “once a season”. Oil, wine and beef prices can move in a quarter. Dish of the day, no salmon, a new dessert — every change is either a reprint or a waiter repeating “we are out of that” at every table. At peak those are minutes you do not have. A guest who waits 12 minutes for a menu then waits for the order, then for the bill. In a business lunch that chain kills the second turn.
- Reprint costs after every price or seasonal change — plus the time until old cards leave the drawer.
- Longer time from seating to first order — slower table turns, especially at lunch.
- Weak upsell: the waiter has no time to suggest a side, and paper does not prompt it next to a photo.
- Languages: English and Ukrainian menus mean extra files, translation errors and a guest guessing allergens.
- Allergens and 86’d dishes — the guest orders something you no longer have and the kitchen loses its beat.
- A second round of drinks that never lands because nobody can catch a waiter for twenty minutes.
- A bill at the end that queues at the till while the next pair waits at the door.
How QR menu table ordering works
A QR code on the table carries the table number — or the guest gets a link after table booking. They open the menu in the phone browser: photos, descriptions, allergens, variants, live prices. They order, with notes (“no onion”, “steak medium”). Kitchen and bar see a ticket with status. Floor staff see what went out and what is waiting. The guest adds more items and pays at the table or at the till. Nobody installs an app-store app.
- A QR code on the table carries the table number (or the guest gets a link after booking).
- They open the menu on the phone: photos, descriptions, allergens, variants, live prices, veggie / spice marks.
- They order, with notes and variants (size, sides, doneness).
- Kitchen and bar see a ticket with status. Floor staff see what went out and what is waiting.
- “Goes well with” prompts and combos sit on the dish, not on the waiter.
- The guest can add a second round without waiting for “anything else to drink?”.
- Pay at the table (BLIK, card) or take a bill at the till — the fiscal receipt stays with the POS.
This is not a PDF behind a QR code
A PDF cannot take an order or drop soup from the menu at 9 pm when it runs out. A PDF does not calculate allergens, switch language, start happy hour at 4 pm or fire a kitchen ticket. A real e-menu is an application: stock, variants, breakfast vs dinner hours, a separate event menu. That is why we connect it with table booking in one panel. A code on the table with no backend is a business card, not a system.
A day in the life with the menu on the phone
11.40 — the kitchen says soup of the day is gone. The manager switches the dish off. It disappears from every table in the same minute. Nobody runs around with tape. 12.10 — lunch. The guest sits, scans and orders before the waiter has finished greeting the next table. The ticket hits a KDS or a kitchen printer. The waiter runs water and plates, not dictation in the noise.
13.05 — the first sitting pays by BLIK at the table. The four is free at 13.20, not 13.45, because the bill did not queue at the till. 18.30 — dinner. A tartare photo and a “house wine with this” prompt lift the average check without pressure. 21.15 — a second round of cocktails leaves the phone while the waiter is at a large table. 22.00 — you switch breakfast off for tomorrow and brunch on for the weekend with a toggle. The print shop is not involved.
- Morning: 86 list, dish-of-the-day price, lunch menu on.
- Lunch: fast scan, ticket, table turn, payment without a till queue.
- Afternoon: happy hour on the bar with no flyer reprint.
- Dinner: photos, upsell, second rounds, kitchen notes.
- Close: what sold, what to switch off, what is on breakfast tomorrow.
Numbers and payback: where the extra turnover comes from
E-menu write-ups from 2024–2026 repeat a similar picture: a well-built QR menu with photos and prompts can lift the average check by several to around fifteen percent. In casual and QSR, 5–15% is a realistic band when upsell is not shouty. Some tourist-market case studies talk about 10–30% with strong photos and translations — that is not a promise for every neighbourhood bistro, only a signal that a phone menu sells differently from paper nobody wants to read in poor light.
The second engine is time. Every minute from seating to order and from “the bill, please” to a free table is capacity. If you cut that cycle by 8–10 minutes at lunch, a second turn stops being theoretical. Do the maths: 20 tables × one extra lunch a week × 45 PLN average × 4 weeks. That is not “digital transformation”. It is several thousand a month for less waiting. Reprints and “we are out of that” errors go away too.
- “Goes well with” prompts and combos — average bill rises without waiter pressure.
- Happy hour and dish of the day with a toggle, no printing and no card on the sideboard.
- A second round while the waiter is at another table.
- Faster lunch turns: menu, order and bill without three staff visits.
- Fewer ticket mistakes: variant and note arrive in writing, not through dining-room noise.
- Translations and allergens always current — fewer send-backs and less stress with foreign guests.
Off-the-shelf QR SaaS or your own ordering menu?
A monthly package is enough when you only want to show a menu, you have one site and you do not care about tickets, table payment or a link to booking. Your own QR menu pays when the card is the heart of operations: several zones, breakfast / lunch / dinner, events, stock, online orders without commission from the same dish list. Then you pay once for an app, not every month for an “upsell module” on someone else’s price list.
- One menu for the floor, delivery and pickup — you change a price once, not in three panels.
- Your own rules: lunch only 12.00–15.00, a kids’ menu at weekends, a hidden event menu.
- A link to table booking and a loyalty programme.
- Order data stays with you: what sells at 13.00, and what only on Friday after 21.00.
- No platform cut on an order from your own table — this is not an aggregator, it is your room.
A staged rollout that does not freeze a shift
We start with the menu and table codes. Waiters can still take an order in the panel if the guest does not want a phone. For a few days traffic is mixed: some tables scan, some order classically, the kitchen gets one ticket format. Then kitchen statuses, table payment, a loyalty programme. Staff get a 15-minute briefing at a live table, not a three-week course.
- Phase 1: e-menu, photos, allergens, languages, table codes. Goal: a live card with no printing.
- Phase 2: order-to-table, kitchen and bar tickets, notes. Goal: less waiting for a waiter.
- Phase 3: 86 toggles, happy hour, combos, upsell. Goal: a higher average check.
- Phase 4: table payment plus a bridge to POS / the fiscal till. Goal: a faster bill and turn.
- Phase 5: loyalty, regular-guest codes, the same menu on delivery and pickup.
Mistakes that cost more than paper
The most common mistake is a PDF behind a QR and surprise that “guests do not order”. Second: a code that is too small, in shadow, with no table number — the guest scans a neighbour’s menu or nothing. Third: forcing an app-store download. Fourth: stock photos that do not look like your dish, so the guest feels cheated. Fifth: taking the waiter out of the process as if QR should replace service. In a full-service room the waiter still greets and advises. The system collects the ticket.
- One code for the whole room with no table number — the kitchen does not know where to send the plate.
- No plan B for a guest without a smartphone or with a dead battery: a waiter must be able to enter the same order.
- A menu without allergens and without the 14 legal marks — that is risk, not “we will keep it simple”.
- Upsell on every line until the card shouts. The guest closes the phone and calls a waiter.
- QR payment with no till link: a manual receipt, a queue and an angry bookkeeper.
- Going live on Friday at 5 pm with no lunch test. The kitchen gets double tickets and chaos.
Rules, allergens and the fiscal till
An electronic menu does not waive allergen and ingredient duties. It makes them easier: you change a mark once and the error on two hundred paper cards disappears. Polish fiscal-till rules do not vanish because the guest pays from a phone. Orders and payments connect to your POS. The fiscal receipt stays with the till you already have or choose. We do not build a “grey till inside a QR”.
Rollout checklist: week by week
Week 0 — dish photos in the real dining-room light, allergens from the paper card, table numbers. Week 1 — e-menu on three test tables, waiters still take orders by voice. Week 2 — codes on the whole floor, one ticket format in the kitchen. Week 3 — 86 toggles and lunch vs dinner. Week 4 — table payment on two tables, then the rest. We do not switch everything on at 5 pm on a Friday.
- Week 0: photos, allergens, table map, a scan test in poor light.
- Week 1: three tables, mixed service, one kitchen ticket format.
- Week 2: the whole room, a 15-minute briefing on every shift.
- Week 3: happy hour, combos, 86 list, second rounds.
- Week 4: BLIK/card at the table plus a POS bridge.
- Month 2: loyalty and the same card for pickup.
QR SaaS vs your own e-menu — a 24-month bill
A 200–400 PLN monthly “menu in the cloud” is 4,800–9,600 PLN over two years, often without tickets and without your lunch logic. Add per-table or “ordering module” fees. Your own QR menu has an implementation cost up front and cheap running costs: hosting, SMS, a gateway. After 12–18 months in a 30+ table venue with a seasonal card, a custom app is usually cheaper than two years of a package that will not join table booking.
Do not count only the subscription. Count reprints (hundreds of zloty per menu change), waiter minutes spent dictating, and one lunch turn that never happened because the bill queued at the till. If the package cannot drop soup at 13.10 on every table at once, you pay for it and for the floor error.
- SaaS: low entry, SMS and “per table” prices that grow with success, data in someone else’s cloud.
- Your own e-menu: higher start, one card with delivery, code and stock with you.
- 24 months: add subscription + caps + missing integrations, not only “200 PLN / month”.
- If you have one site and only show a menu — SaaS can be rational. We will say so.
Staff, change resistance and what to measure after 30 days
Waiters fear QR will take the tip and control of the table. In full service the role stays: greeting, wine advice, plates, guests without a phone. The system collects the ticket and the second round. After a month you look at three numbers: time from seating to first ticket, average check vs the month before, share of tables that scanned at all. If scans are below half, the problem is the code (too small, in shadow) or the greeting (“the menu is on your phone” works better than a silent stand).
If you reprint menus every month or lunch stalls because no waiter is free — this is the system. Tell us table count and whether you want menu-only or ordering too. Quote in 24 hours. If e-menu without tickets is enough to start, we will say so and leave a path to order-to-table in phase two.
Frequently asked questions
- Does a QR menu need an app store app?
- No. The guest scans and opens the menu in the browser. Nothing to install. An Android app makes sense later, with loyalty and push, not for the first card.
- What if a guest does not want to order on a phone?
- Staff take the order in the same panel. One kitchen ticket, whichever channel. QR is an extra door, not the only one.
- Can we hide dishes that have run out?
- Yes — you switch a dish off in the panel and it disappears from every table at once. That is one of the things a PDF cannot do.
- Does this replace the fiscal till?
- No. Orders and payments connect to your POS. The fiscal receipt stays with the till you already have or choose.
- Will waiters lose tips?
- In full service the waiter stays at the table: greet, advise, run plates. A faster turn and a higher bill usually do not cut the tip — they cut waiting. You can also add a tip on table payment if you choose to.
- How many tables can the system handle?
- From a small café to a hundred covers and a terrace. Each table has its own code. The kitchen sees numbers, not “someone ordered from a QR”.
- Can the lunch and dinner menus differ?
- Yes. Hours, zones, events, a bar list. A toggle, not a new InDesign file.
- How does it pay back?
- Fewer reprints, a higher average check from upsell and a faster lunch turn. One extra table turn a week often covers phase one in a few months.
Related service:
Custom software for companies
Describe your project