By Bader Omar, co-founder of ScaanMe - 8.27.2026
Watch a four top get seated on a Friday at full covers. Someone scans the code on the table tent, waits, turns the phone sideways, pinches to zoom, drags the page around with one finger to find the appetizers, then gives up and asks the server what the specials are. The table has a menu. The restaurant has an execution problem it is reading as guests disliking QR codes.
This publication argued last month that Starbucks was right to retire a computer vision inventory system that miscounted items badly enough that staff recounted by hand, because a tool people have to verify has added a step rather than removed one. Apply that test at the table. If the guest scans the code and then asks the server the question the menu was supposed to answer, the menu added a step instead of removing one.
The concept is not the problem. Operators who dropped QR menus and went back to laminated cards mostly did not drop a bad idea. They dropped a bad implementation, and the specific failures are boring, mechanical and fixable.
A QR code is a printed hyperlink, and everything after it is software
Once the phone camera fires, you are running a web application in the worst conditions your operation produces: an unfamiliar device, one hand, poor light, a saturated cell tower, and a guest who will give up quickly and ask a server instead.
The most common implementation is to hang the print PDF that already went to the laminator behind the code. That is the worst choice available, and it explains a large share of the complaints operators blame on QR menus generally.
A PDF is a picture of a document. It does not reflow, so a page laid out for eleven inches of paper stays laid out for eleven inches of paper on a four inch screen, and the guest does the layout work by pinching. It downloads in full before the first readable pixel arrives, which is why the menu feels broken on a weak signal even when the connection eventually succeeds. It cannot be filtered, so a guest looking for something gluten free reads all six pages. A screen reader handles it poorly or not at all. Search engines and the assistants your guests ask for recommendations cannot read the dish names inside it as text.
Every one of those is a guest complaint that arrives at the host stand as “the QR thing does not work.
Count the hops between the code and the food
Follow the URL actually encoded in your table tent. In a lot of operations it goes to a link shortener, which redirects to a marketing domain, which redirects to a menu subdomain, which redirects again to add a language or location parameter. Four hops.
On house wifi that chain is invisible. On a congested cell in a basement dining room, each hop is a fresh name lookup and a fresh encrypted handshake before any content moves, and the guest watches a spinner.
Hand this line to whoever runs your website and ask for the output:
curl -sIL -o /dev/null -w '%{num_redirects} redirects, %{time_total}s\n' "PASTE_THE_PRINTED_URL_HERE"
The target is zero redirects. One is tolerable. Anything more is latency you are paying for at every table, every service.
The second problem in that chain is not about speed. If the domain encoded in your table tent belongs to a shortener or an agency, your printed assets sit on somebody else’s renewal calendar. When that account lapses, every tent, decal and menu board in the building points at nothing, and the fix is a reprint. Encode a domain you own, point it at one canonical URL, and do the redirecting on your own infrastructure, where you can change the destination without touching the print.
Test at the worst table, at the worst hour
A menu that assumes a live data connection fails exactly when the room is full, which is the only service where it matters. Basements, converted stone buildings, patios behind a wall, any room where a few hundred phones compete for the same tower.
A well built QR menu renders from the phone’s own cache on a repeat visit, so a returning guest gets the menu instantly and a first-time guest on a dead signal at least gets the shell. That is standard web technology, and any competent developer can add it.
It carries one trap, and it is a pricing risk rather than a technical curiosity. Offline caching works by installing a small piece of code on the guest’s phone, which then keeps serving the version of the menu it already holds. So the cached menu has to be versioned, or a price change never reaches the phone. And when you retire a menu, seasonal, location closed, concept changed, that address has to answer with the status that means permanently gone, 410, rather than an ordinary 404 not found. A 404 leaves the installed code on the guest’s phone, where it can keep showing a menu you no longer serve at prices you no longer charge, with no trace in your analytics because the phone never contacts your server to render it.
Ask your provider one question: what happens on a guest’s phone after we take a menu down. If nobody can answer it, you have found something worth fixing.
Scan the printed piece, not the artwork
The design file is not the object on the table. A proof reviewed on a screen tells you the code looks correct. It does not tell you what the code says, and a QR pointing at a staging address or a template placeholder looks identical to a correct one at a glance.
Four print failures show up repeatedly on real table tents. A code reversed out light on dark stock, which inverts the contrast the scanner expects. A logo dropped into the middle large enough to eat the error correction the code needs to survive it. A missing quiet zone, meaning the code sits crowded against a border or the edge of the panel. And a code positioned where a fold, a notch or a card sleeve cuts across it.
The check costs nothing. Take a piece from the delivered print run, not the file, and scan it with two phones under your own dining room lighting, at the angle a seated guest holds a phone. Then ask your printer or developer to decode the press ready file programmatically before the next run. A screenshot review cannot read a QR code. A decoder can.
If you serve a second language, read your own hours
Bilingual menus fail in ways that pass every automated check. Two show up constantly.
When a translation is missing for a menu item, most systems do not show an error. They fall back to the English source text, so the Arabic menu quietly serves English dish names for everything added since the last translation pass while the system reports the page as fully translated. The check is manual: open the second-language menu on a phone and read it end to end after every menu change.
The other is stranger. Opening hours written in Arabic can display reversed, so a venue open 9:00 to 17:00 shows as 17:00 to 9:00. That is the Unicode bidirectional algorithm behaving exactly as specified when a Latin number range is dropped into right-to-left text without being isolated. The fix is one attribute in the markup. The point for an operator is that no spell check, no translation vendor and no automated test will catch it. Somebody has to look.
What to check this week
- Pull one table tent off a table and run these five.
- Scan it and time how long until you can read a dish name. Anything past three seconds on cellular is a problem.
- Run the curl line above on the encoded URL and count redirects.
- Look up who owns the domain inside the code, and whether that renewal is on your calendar.
- Open the menu and try to select a dish name as text. If you cannot, it is a picture, and neither a screen reader nor a search engine can read your menu.
- Change a price in your system, then reload the menu on a phone that has already visited once. If the old price is still there, your caching is not versioned.
None of this needs a new vendor or a budget cycle. It needs somebody in your operation to hold a printed piece of cardboard, at the worst table, at the busiest hour, and behave like a guest for ten minutes.
Bader Omar is co-founder of ScaanMe, a bilingual Arabic and English digital identity platform based in Amman, Jordan. “Replace printed menus permanently with a smart, always-current digital menu that lives behind a QR code. Customers scan from their own phone and browse a full-photo menu in their preferred language. You update prices, add seasonal dishes, or mark items sold-out from your phone in seconds, no reprinting, no crossing items out, no outdated PDF.” He works across restaurant, retail and hospitality deployments in Jordan and the Gulf, where the team builds QR menus, ordering front ends and wallet passes for operators serving guests in two languages and two numeral systems.
Are you an industry thought leader with a point of view on restaurant technology that you would like to share with our readers? If so, we invite you to review our editorial guidelines and submit your article for publishing consideration.
