In questa pagina
A QR code on the table is a good tool. It replaces a stained paper menu for the person who is already in the chair. It does not bring the next person through the door. Those are two different jobs, and most "digital menu" products only do the first.
Who the QR is for
The guest scans because they are hungry and the paper is missing, not because they discovered you. The QR has to load fast, show the dish, the price, and the allergens, and work on a phone in a dim room. If it needs an app install, you have already lost the table.
That job is real, and it is enough reason to keep the menu updated. Lunch, Sunday, and the Christmas set are different cards. A single PDF from last spring is how you sell a dish you no longer cook.
Who search is for
The person on the street, or on the sofa, is asking a different question: where can I eat this dish, open now, near me. They will not scan your table. They will type the dish into a search box, sometimes into Google before they ever hear your name.
A public page with the restaurant name, the address, the hours, and the menu written as data is what that search can rank. A QR that only exists inside the room is invisible to it. FinderFood is built so the same menu does both: the code on the table, and the listing that a dish search can find.
What to publish
Publish dishes, not a photo of a menu. A photo cannot be filtered for vegan, gluten, or price. Write the name a guest would search, in the language you cook in. Add the price in euros. Mark the allergens you are legally already tracking. Set the hours you actually keep, including the day you close.
Then print the QR. The order is the menu first, the code second. The code is a door for people who found the door. The listing is how they knew the door was there.
A small test
Search for your signature dish and your city. If your room does not appear, the QR on table 4 cannot fix it. Update the dish. The guest who is already seated will see it tonight. The guest who has not chosen you yet can see it tomorrow.
