GUIDE
What to decide before commissioning a QR menu
Four decisions come before a QR menu. Where the menu lives, who updates it, whether paper stays, and how the code sits on the table.
·
Written by Erdem G. · İZVELA
A QR menu is a digital menu that opens when a code on the table is scanned with a phone camera. It either replaces the paper menu or sits alongside it. The real difference is that the content is no longer tied to printing. When a price changes the menu is not reprinted, it is updated in one place and changes on every table at once. This guide covers what to settle before commissioning one.
Where should the menu live?
Two options. A menu built as part of your own website keeps visitors on your domain, feeds your search visibility and stays yours. A menu on a third-party platform is quicker to start but the address belongs to someone else, and if the service closes or raises its price the menu goes with it. For a business that intends to stay, the first option is the safer one.
Who updates it, and how often?
This decides more than it looks. If updates require calling an agency every time, prices drift out of date. The workable setup is one where the business itself can change prices and add seasonal items in minutes. We hand the menu over with that access and a short walkthrough.
Put a limit on the number of categories as well. If there are more than 10, simplify the list and move the best selling and most profitable items to the top of each category. A price change on a properly built menu goes live within minutes, which ends the era of stickers on the table.
Does the paper menu disappear?
Not necessarily, and often it should not. Some guests prefer paper, and a table with no signal needs a fallback. A common arrangement is a short printed menu for the core list and the QR code for the full range, seasonal items and campaigns. The code itself has to be readable without being an eyesore, which is where a table stand earns its place.
Where should the code go, and how big?
Placement follows one rule. The customer should be able to scan it without getting up or reaching across the table. A table stand is the common answer because it stays visible and stays put. Printed on a card or on the wall works too, as long as something on the table points to it.
For size, a simple ratio works. The width of the code should be roughly a tenth of the scanning distance. A code read from twenty or thirty centimetres on a table works comfortably at three or four centimetres. One on a wall read from a couple of metres needs to be fifteen to twenty. Codes printed too small fail in low light, and a customer who fails once does not try twice.
What if the customer has no connection?
The menu loads over the internet, so a connection is required, and in a room with no paper menu that is a real problem. There are two practical answers. Offer a guest network, and keep a couple of printed copies behind the counter as a fallback.
The second sounds minor but it protects the experience. Moving to a digital menu does not have to mean removing paper entirely. The point is to end the printing cost and the delay in updating prices, not to leave a guest stranded.
Do guests need an app?
No. Current phone cameras read QR codes directly. The menu opens in the browser like any web page, with nothing to install.
Can the menu be bilingual?
Yes, and in areas with foreign guests it is worth doing from the start. The same menu carries a language switch, so one code serves everyone rather than printing a second set of cards.
Is there a monthly fee?
Not for the menu itself. Setting it up is a one-time cost, and after that the menu is simply a page on your own site. The annual technical maintenance that comes with every site already covers it, so the QR code adds no separate recurring line. There is also a monthly option and it is entirely optional. That one suits owners who would rather we handle menu updates and the Google Business Profile than do it themselves, and the menu works without it. Current figures are on the Plans page.
How long does it take?
The build itself is quick once the content is ready. What actually sets the timeline is how complete that content is when work starts. Categories, prices, item names and any photos, all confirmed and gathered in one place, let the build move straight through without pausing. Anything still being decided on the client side, a missing price or a photo not yet taken, is what pushes the date back instead.