Does QR ordering actually work for restaurants?

QR ordering arrived in Indian restaurants as a pandemic necessity, was oversold as the future of dining, and then collected a backlash — guests complaining about squinting at a PDF, restaurants finding it made service worse rather than better. Both waves were about implementation, not the idea.

The useful question is narrower: in which situations does a guest ordering from their own phone actually beat a person taking the order?

Where it clearly wins

The second round

This is the strongest case and the one most often missed. Taking the first order is a service moment worth having a person for. Getting a second coffee, an extra portion of fries or the bill twenty minutes later is not — it is a guest trying to catch someone's eye across a busy room. QR ordering turns that into three taps, and it is exactly the order that gets lost otherwise.

Peak-hour counters

When there is a queue, every guest who orders from their table is one fewer person in it. The bottleneck at a busy café is usually order-taking, not the kitchen.

Understaffed shifts

A Sunday with one person short is where QR ordering earns its keep — not by replacing a server, but by making an eight-table section survivable.

Menus that need explaining

A photograph, a description, a veg marker and a visible add-on list do a job a laminated card cannot. Guests order more confidently when they can see what a dish is.

Where it genuinely fails

• Fine dining and anywhere service is the product. If a guest is paying for attention, removing the person is removing what they bought.
• A PDF instead of a menu. A scanned image that has to be pinch-zoomed is worse than paper in every way. If the menu is not a real, item-by-item mobile page, do not deploy it.
• Older guests and large groups. Both need a person. Any QR rollout has to keep the option of ordering the normal way, always, without it feeling like a concession.
• Weak signal. A café in a basement with no mobile data and slow Wi-Fi will produce a guest staring at a loading spinner. Fix the connectivity first.
• Forcing an app install or a long signup. Every extra screen loses guests. Ordering should need a name and a number at most.

What separates a good implementation from a bad one

1. It is the same menu the counter uses. If the QR menu is a separate copy, it will drift out of date and a guest will order something that ran out at lunch.
2. Sold out means sold out, immediately. Marking an item unavailable has to reach the guest's phone at once.
3. The order goes straight to the kitchen. If someone at the counter has to re-key it, you have added a step rather than removed one.
4. The table number comes with the order. Obvious, and routinely got wrong.
5. It loads in seconds on a mediocre connection. Lazy-loaded images and a cached menu, not a heavy page.
6. Paying is optional. Some guests will pay online; many want to pay at the counter. Both have to work.

How to roll it out without a mess

Do not put a QR on every table on day one. A sequence that works:

1. Start with four tables, ideally the ones furthest from the counter.
2. Keep taking orders normally at every other table.
3. Watch what breaks for two weeks — usually item descriptions, not the technology.
4. Ask the staff, not the guests, whether it made the shift easier. Staff notice first.
5. Expand only if the answer is yes.

And keep the framing right with guests: the QR is an option, not a replacement. A table tent that says "scan to order, or just wave — either works" converts far better than one that implies nobody is coming.

The honest summary

QR ordering is a genuine improvement for repeat orders, peak hours and short-staffed shifts, and a genuine downgrade for anywhere service is the point. It is worth doing if — and only if — the menu is a real mobile page tied to the same data your counter uses, and ordering the old way stays available. KhaoPiyo's implementation is described on the QR ordering page; the criteria above apply to any of them.