The Simple Logic Behind QR Table Ordering

QR table ordering looks like magic to guests, but the logic behind it is simple. Here is the shape of it, from a product point of view.

1. One link per table Each table gets a QR code that points to the restaurant's menu, with the table identified in the link. When a guest scans it, the browser opens the menu already tied to that table. No app install, so there is almost no friction.

2.** A clear order status flow**
Orders move through a small, predictable set of states:

Confirmed -> Preparing -> Ready -> Served -> Completed

The kitchen and the guest see the same status, which cuts down on "where is my food?" questions.

1. Stopping orders from the wrong place
   A photo of a QR code could be used from home. One fix is a location check: the guest shares their location, and the order is accepted only within a set distance of the restaurant. TasteZaika uses 100 metres by default, adjustable in settings.

2. Real-time for staff
   New orders appear on a dashboard straight away, can be read aloud, and can be printed as a kitchen ticket (KOT) on an 80mm thermal printer for kitchens that prefer paper.

What I would still keep simple
Dine-in only, not delivery
Guests pay the way they do today
A few paper menus as a backup
Try it
Disclosure: this is about TasteZaika, a QR ordering tool for restaurants and cafés that I work on. Registering is free https://tastezaika.com/.

If you have built something similar, what edge case surprised you most?