QR ordering that guests actually use

During the pandemic every restaurant printed a QR code. Most of them pointed at a PDF of the existing menu. Guests pinched and zoomed, gave up, and asked for a paper menu. That experience taught a lot of operators that QR ordering does not work, when what it actually taught them is that a PDF is not an ordering system.

What separates a menu from an ordering flow

• The page is built for a phone screen, not zoomed from A4.
• Items carry photos, descriptions and modifier choices — spice level, portion, add-ons.
• Out-of-stock items disappear the moment the kitchen marks them off.
• The guest can place the order themselves, not just read it.
• Payment can happen up front, so the settle step disappears at the end of the meal.
• The order goes to the kitchen station directly — no captain re-typing it into the POS.

The 86 problem

Nothing damages the experience faster than ordering a dish that ran out an hour ago. When the kitchen marks an item unavailable, that change has to propagate to the QR menu, the takeaway site and every aggregator listing within the minute. If availability lives in four places, it will be wrong in at least three.

One master menu, published everywhere. Change it once; it changes everywhere.

Where the labour actually goes

The saving from QR ordering is not headcount — it is the captain's walk. Taking an order, walking to the terminal, keying it in, and walking back is three to four minutes per table per round. Removing the keying step lets the same staff cover more covers without rushing guests.

Keep the human in the loop

The best implementations do not remove service; they redirect it. Captains stop being order-takers and start being hosts — recommending, pacing courses, handling the table. Guests who want to order verbally still can. QR is an additional path, not a replacement for hospitality.