View-only or ordering?
| View-only menu | QR ordering | |
|---|---|---|
| What the guest does | Reads the menu, then calls a waiter | Reads and sends the order |
| Prices and sold-out dishes | A PDF goes stale; a live page does not | Must be live, or orders fail |
| Staff needed | The same | Fewer trips, but someone must watch orders |
| Risk | None | Orders nobody meant, or a joke from the next table |
| Best for | A small menu, full table service | Busy tables, cafés, repeat orders |
Stopping fake and mistaken orders
This is the question every owner asks, and the answer is a person. A QR can be scanned from anywhere, and a phone number typed by a guest proves little.
- Confirm before cooking: the order waits on the counter and waiters’ phones until someone reads it back to the table.
- A code per table: so the order is tied to a table, not just your restaurant.
- Switch-off dishes: a dish you just ran out of should not be orderable.
- Decline with a reason: so the guest’s page says what happened.
Printing and placing the code
- One code per table, with the table number printed beside it.
- At least the size of a playing card, at a height a phone can reach.
- Laminated, or in a stand: curry and rain ruin paper.
- One line in your own language: “Scan to see the menu and order.”
- Test every code on a cheap phone, with mobile data, before you stick it down.
What guests dislike, and what to do
- Being forced to use a phone: keep a few printed menus.
- Downloading an app: it should open in the browser.
- Slow pages on poor signal: test at your own table.
- Feeling ignored: QR ordering should free your staff to look after people, not replace them.
How to start
- Put your menu online with live prices.
- Try it on two tables for a week.
- Keep the waiter’s check on.
- See what goes wrong, and fix the menu’s wording and photos.
- Then roll out to the rest.