Ordering at the table by QR: how to design the flow

Ordering at the table by QR takes five steps: the guest scans the code, reads the menu in their phone's language, picks, sends, and the order shows up on the restaurant's tablet. Here's each step and why it's worth building that way.

1. Scan and you're in the menu, no app

Nobody installs an app to order a coffee. That's why table ordering works best as a web app: the phone's camera reads the code and the menu opens in the browser. For table ordering, the code on each table has to lead to the same menu while also saying which table the order is from, so the waiter doesn't have to ask.

That also changes what needs printing: the code on the table stays the same, while the menu behind it can change at any time. You'll find more about digital menus in general on our digital menus page.

2. The menu in the phone's language

A tourist from Germany shouldn't have to hunt for the language button on a menu in Romanian. The browser tells the site which languages the person prefers: the navigator.languages property returns them in order of preference, most preferred first. The same list reaches the server in the Accept-Language header.

So the menu can open straight in the phone's language. A visible language switch is still useful: phones aren't always set to the language people want to read in, and some browsers send only one language for privacy reasons.

3. Allergens next to every dish

Regulation (EU) No 1169/2011 requires allergen information for food served on the premises too, not just for packaged food (Article 44), and Annex II lists 14 allergen groups. Member states can decide how that information reaches the customer.

In a digital menu, the simplest approach is to put allergens right under each dish, in the language the guest picked. A tourist with a sesame allergy may not share a language with the waiter, but they can read the screen.

4. A basket built for the thumb

People order one-handed, often holding a glass in the other hand. Buttons need to be big and well spaced. The WCAG 2.2 accessibility standard requires, at level AA, that pointer targets be at least 24 × 24 CSS pixels, with a few exceptions. That's a floor, not a goal: the buttons people use most, "add" and "send order," deserve to be much bigger.

Before sending, the basket should show everything: what you picked, quantities, notes ("no onions"). A wrong order sent to the kitchen costs more than one second of checking.

5. The order shows up on the tablet, live

The part the restaurant feels most is the tablet. Orders have to appear on it right away, without anyone refreshing the page. For that, the tablet keeps a connection open through which the server pushes new orders as they come in.

One technique that fits is called server-sent events: a one-way connection from server to browser that reopens on its own if it drops. For a tablet on a restaurant's Wi-Fi, where the signal does drop, automatic reconnection matters. MDN's documentation notes one limit: without HTTP/2, a browser can keep at most 6 of these connections open to the same domain. It's a detail to keep in mind when choosing the server setup.

If you want an app with live orders for your business, our App Dev services page shows how we work.