QR codes for a restaurant menu

The QR menu is the clearest case for a dynamic code there is: the paper on the table is cheap to print once and annoying to reprint every week, and the menu behind it changes constantly. This article covers how to set it up so that the codes on your tables are the last ones you print, and it is equally honest about what the scan numbers can and cannot tell you.

Table tents and the first print

A table tent, a sticker on the table, a card in the menu holder or a small sign at the counter: whatever carries the code, it is going to be laminated, handled, wiped and left in place for months. That is exactly the situation where a static code becomes a liability, because the day the menu link changes — a new PDF, a new ordering page, a new domain — every one of those pieces is wrong at once. Set the code up as dynamic before the first print, so that the pattern encodes a short redirect link and the destination lives on the server where you can change it. Print it at a size that reads from a seated position: a table tent is scanned from roughly 30 to 50 centimetres, so a code of 3 to 5 centimetres is comfortable, and there is no reason to go smaller. Use the SVG export for the print shop, keep the four-module quiet zone clear of the decorative border, and prefer a matt laminate — a glossy one throws highlights under pendant lighting that can blank out part of the code. Print one, put it on a table, scan it with a phone from a chair, and only then order the batch.

Menu changes, specials and seasonal swaps

Once the codes are dynamic, a menu change is a change of destination, not a reprint. The winter menu goes live in November by pointing the code at the new page; the summer one comes back in May the same way. A weekend brunch menu can replace the regular one on Saturday morning and be swapped back on Monday. A dish that has run out can be removed from the page without touching the tables. A move from a PDF to a proper ordering page, or from one ordering provider to another, is one edit rather than a reprinting job. Because the destination is just a link, the code works with any menu format: a PDF, a web page, a form, a photo album, an ordering system. Two practical habits make this smooth. Give each code a label only you see — "Tables", "Counter", "Window sign" — so you can find the right one when the list grows. And keep the destination page stable in its own right: change the content of the menu page rather than its address whenever you can, so that the redirect rarely needs touching at all and the code is only there for the day it does.

One code per table, or one code for all?

The simplest setup is one dynamic code printed on every table and every sign. It is cheaper to manage, and a change of destination applies everywhere at once. Its limit is that the scan statistics are pooled: you learn how often the menu was opened, not from where. One code per table, or per zone, gives you separate counts — the terrace versus the back room, the window sign versus the counter card — at the cost of more codes to manage and, in this app, a paid plan, since the free tier includes a single dynamic code. It also allows each code to point at a slightly different page, for instance a terrace page that lists the outdoor-only specials, or a counter code that goes straight to takeaway ordering. Most places do well with a small number of codes by location rather than one per table: it tells you which placements earn their space without turning the code list into a chore. Whatever you choose, the codes should look identical to guests; the difference is in the short link, not the design.

What scan statistics can and cannot tell you

Every scan of a dynamic code is a request to the redirect service, and that request is what gets counted. From it you can see how many scans happened, when they happened, and what kind of device made them — the phone's browser identifies itself in general terms, and the request's network address can be resolved to a rough country. SWAPQR's statistics panel shows totals for today, this month and the last 30 days, broken down by day and by device type. That is enough to answer the questions a restaurant actually has: is the code being used at all, does lunch or dinner drive more scans, did the window sign do anything, did scans rise after the new sign went up. It is not enough to answer anything about a person. There is no name, no email, no phone number, no table number unless you printed different codes, no camera access and no way to link one scan to another with confidence. A phone that opens the menu three times is three scans, and whether it was one guest or three is a guess. Treat the numbers as a trend line, not as a customer list, because that is what they are.

Keep a paper menu

A QR menu does not replace a printed one; it sits beside it. Some guests have no phone with them, a flat battery, no data, a phone that cannot read codes, poor eyesight, or simply no wish to read a menu on a five-inch screen. Children, older guests and anyone who finds small text hard all do better with paper, and accessibility rules in some places expect a non-digital option to be available. The right setup is a QR code on the table for the guests who prefer it, and a printed menu available on request — which also means the printed menu has to be kept current, so build the update of the paper copy into the same routine as the update of the destination page. Make the menu page itself readable on a phone: large type, no tiny PDF that needs pinching, and no requirement to install an app or hand over an email address to see a list of dishes. The code is a shortcut to the menu, and a shortcut that leads to a wall is worse than no shortcut.