What QR ordering actually is
QR code ordering lets a guest scan a printed code with their phone camera, open the restaurant menu in their browser, and place and pay for an order without a staff member taking it. No app is installed. The order arrives in the kitchen the same way a counter order does.
It is worth separating three things that often get lumped together, because they have different economics and different failure modes:
- A QR menu. The code opens a menu to read; a server still takes the order. Cheap, low risk, and the least useful of the three.
- QR order-and-pay at the table. The guest orders and pays themselves. Real labour and turn-time effects, and real ways to annoy people.
- QR as an off-premise entry point — on a flyer, a delivery bag, a shop window. Closest to online ordering, and the one most operators under-use.
Where it works
- High-turn casual dining, where the bottleneck is a server reaching the table rather than the kitchen.
- Bars and beer gardens, where the walk to the counter is the whole friction and re-orders are frequent.
- Large or spread-out rooms — terraces, function spaces, anywhere a server does not pass often.
- Counter-service rooms with a queue, where a seated guest can order without rejoining it.
- Reorders off-premise: a code on the delivery bag is the cheapest repeat-order channel a restaurant has.
Where it backfires
The honest list, because ignoring it is why so many rollouts were quietly reversed:
- Where service is the product. If guests are paying for hospitality, handing them a form is a downgrade.
- Where it replaces staff rather than freeing them. Removing the server from the table removes the upsell, the check-back, and the recovery when something is wrong.
- With guests who will not or cannot use it. Older guests, a flat battery, no data, poor eyesight. A QR-only room excludes paying customers.
- Split payments. The most common complaint by some distance. If four people at a table each order on their own phone, decide in advance whether that is four checks or one.
- Tipping. Tips typically shift when the prompt moves from a person to a screen. Know which way before you commit, and tell your staff.
The rule that emerges: QR ordering should be an additional lane, not a replacement for the staffed one.
Printing and placing the codes
- One code per table, not one per restaurant. A code that knows where the guest is sitting is the difference between ordering and a menu PDF.
- Say what it does. "Scan to order and pay" substantially outperforms a bare code — people do not scan unexplained squares.
- Test it printed, at the size you will print it, under your actual lighting. Codes that scan happily on a monitor can fail on a dim table.
- Laminate, or use table tents. Paper codes on a dining table have a short life.
- Make them replaceable. Codes get taken, defaced, and occasionally stickered over by somebody else. Rotating one should not mean reprinting the room.
- Put one on the takeaway bag. The cheapest reorder prompt available to a restaurant.
What to ask before rolling it out
- Does the code carry the table? If not, somebody is asking guests for a table number, and you have added work rather than removed it.
- What happens with a shared table? Separate checks, one running check, or a merge at the end.
- Does the guest need an account? Requiring sign-up before browsing loses orders.
- Does an 86 reach the QR menu immediately? Selling something the kitchen ran out of is worse on a phone than at a counter, because nobody catches it.
- Can a code be rotated or revoked without reprinting everything?
- Can you tell whether it is being used? Scan counts per code turn a guess into a decision.
Where ThaliPOS fits: codes are generated per location and per area within it, carry an opaque short code rather than internal ids, can be rotated or revoked with an audit trail, and record scans per code. The ThaliPOS QR ordering page →