All posts

QR code menus: the setup that survives service

8 min readRestaurantsOperations

LAMINATED ONCE · CHANGED DAILY

The QR menu survived the era that created it because it solves a real restaurant problem: menus change faster than print does. But most implementations still fail in the same two ways — a code pointing at a stale PDF nobody can update mid-service, or a code that worked until somebody's free link-shortener trial ended. Both are setup mistakes, and both are avoidable on day one.

The architecture: one laminated code, moving destinations

Print each table's code once, laminate it, and treat the destination as part of running the kitchen. Tonight's specials, the weekend brunch card, the festival menu for one week — each is a repoint, done from a phone, live on the next scan. There is no cached yesterday's menu, because the redirect resolves live every time.

laminated oncebreakfastlunch — live nowthe festival cardrepointedfrom the kitchen
The loop that makes a laminated code permanent: destinations rotate behind it — breakfast, lunch, the festival card — edited from the kitchen while the print never changes.

The Wi-Fi code is the opposite decision

The other code every table wants is the Wi-Fi — and it should be static: network name and password encoded directly in the grid, so phones join even when your internet is down, which is precisely when everybody asks. Make it free forever with the Wi-Fi generator; static codes cost nothing on any plan because there's nothing to serve.

Size for the table, not the poster

Table codes are scanned from 40–70 cm, usually one-handed, sometimes in candle-adjacent light. The 10:1 rule says 5–7 cm of code; lamination glare argues for the top of that range and strong contrast rather than the brand's subtlest tone.

30 cm — in hand≥ 30 mm60 cm — tabletop≥ 60 mm1.5 m — poster≥ 150 mm3 m — banner≥ 300 mmSCAN DISTANCE ÷ 10 = MINIMUM PRINT WIDTH
Where a menu code sits on the distance ladder: tabletop scanning wants roughly 6 cm of printed code — bigger if the lamination glares or the lighting is ambitious.

What the scans quietly teach you

Because each table's code is its own code, the analytics become floor intelligence: which tables scan, at which hours, how many unique visitors an evening actually brought. A folder per branch keeps a group's locations comparable — and none of it stores an IP address or follows a diner anywhere, which is the correct answer when a customer asks what the code collects.

The checklist that survives contact with service

  • One dynamic code per table (or per venue if you don't need per-table data), named after the table — future-you will thank present-you in the analytics.
  • Menu hosted somewhere you can edit — your site, or a hosted landing page if there's no site to point at.
  • A static Wi-Fi code beside it, tested on both an iPhone and an Android before printing.
  • 6 cm print, dark on light, quiet zone respected — then a proof scanned at a real table with the oldest phone on staff.
  • Artwork through the scannability checker before the laminator does anything permanent.

The longer operational version — multi-location folders, per-branch reporting, seasonal swaps — lives on the restaurants page. The short version is the discipline above: laminate geometry, keep the meaning editable, and the menu code becomes the one piece of print that never goes stale.