Table QR menus: what actually works in an Indian restaurant

A QR menu is not a cost saving. It is a pricing tool. Restaurants that treat it as a laminated card replacement usually abandon it within a season; the ones that keep it are the ones who change something every week.

Use one code per table, not one code per restaurant

A single code on a poster tells you nothing. A code per table tells you which sections fill first, how long a table takes to order, and which corner of the room never gets a second round. Print the table number into the link itself, so the ordering page already knows where the customer is sitting.

Make it dynamic before you print anything

A static code encodes your menu link permanently. When your menu URL changes — and it will, when you move platforms or restructure your site — every printed code becomes dead plastic. A dynamic code points at a short link you control, so the artwork on the table never has to change again.

Size and placement matter more than design

A code should be at least 2.5 cm across for a phone held at arm's length, and 4 cm if it sits flat on a table under glass. Glare kills more scans than bad design does: matte lamination scans, gloss under a ceiling light often does not.

Put the review code somewhere else

Asking for a review on the same code as the menu gets you neither. Put the menu code on the table and the review code on the bill folder, where the meal is finished and the opinion is formed.

What to check after two weeks

• Scans per table — a table with none usually has a lighting or placement problem
• Device split — if desktop scans appear, someone is sharing your link, which is worth knowing
• Time of day — tells you whether the code works at dinner but not at lunch, when the light changes

All of that is visible in the analytics on any dynamic code, at no cost.