Walk into most restaurants and there is a printed menu on the table with at least one price on it that is no longer true. Not because anybody is dishonest. Because reprinting is a project, and projects lose to service.
The gap between the price on the card and the price in the till is one of the most common, least discussed costs in hospitality. It is worth looking at what actually causes it.
Why the reprint does not happen
It is never the printing. Printing is cheap and fast. It is everything before it.
The menu lives in a design file. The design file lives with the person who made it — an agency, a freelancer, a nephew, a former colleague. To change one price you need that file, that person, and their availability. Then a proof, then a correction, then the print.
So a two-cent change becomes a two-week errand, and it does not get made. Instead the price rises in the till, the printed card is left as it is, and the difference becomes an argument at the table.
Meanwhile the same thing is happening in parallel to the PDF behind the QR code, the menu page on the website and the lunch board outside. Each is its own errand with its own owner. All of them drift.
What it costs, concretely
The costs are small individually, which is exactly why they never get counted.
The correction at the table. A guest points at the printed price. The staff member either honours the old price and you lose the difference, or explains the increase and the guest feels misled. Both are worse than being right.
The reprint you postpone. Because a reprint is a project, restaurants batch it. So one round of supplier increases sits unreflected for months, across every cover, on every dish that moved.
The dish you cannot take off. A supplier stops, a chef leaves, a season ends. The dish stays on the card because taking it off means the same errand. Now the kitchen apologises for it several times a night.
The languages you never printed. Half the room reads another language. A second version means the whole process again, so it stays a plan.
The seasonal card you skipped. An autumn menu, a Christmas card, a wine list update — each a good idea that dies at the words "we would have to redo the menu".
None of that appears on an invoice. It appears as a slightly worse restaurant.
The fix is not a nicer design tool
The instinct is to look for easier design software. That misses the point. The problem is not that the layout is hard to edit. It is that the printed menu is a copy of the menu, disconnected from the dish data your restaurant actually maintains.
As long as it is a copy, it needs its own update cycle, and that cycle will keep losing.
The alternative is to generate the printed menu from the dishes themselves. The printable menu in Restaurant Hub does exactly that: the names, descriptions, prices, portion sizes, allergen markers and translations you already maintain become the document.
You set how it prints, not what it says:
- paper size, portrait or landscape, margins, columns and content density
- language and currency, and whether to show prices, descriptions, allergen markers and photos
- which categories appear and in what order, food and drinks grouped or mixed, unavailable dishes skipped
- your logo, menu title, footer text, QR code, accent colours and font
- a print design — Elegant, Classic, Minimal and further styles — with a live page-by-page preview
When a price changes, you generate a new version and print it. There is nothing to rebuild, because there was never a second copy of the menu to begin with.
What that makes possible
Once the printed menu costs minutes instead of a fortnight, decisions change.
Prices stay honest. A round of increases reaches the table the same week, not next quarter.
Unavailable dishes disappear. The lunch card can be generated with unavailable items filtered out, so the kitchen stops apologising.
A second language becomes reasonable. Language is a setting on the document, not a new project. If half your guests read another language, print for them too.
Separate cards stop being a luxury. A wine list with its own paper size and density, a lunch card, a seasonal menu — each keeps its own configuration and is generated from the same dishes.
The card and the phone finally agree. The digital QR menu and the printed card read from the same data, so a guest comparing the two sees the same prices. That sounds obvious. Go and check it in your own dining room.
Where the daily specials belong
One more thing worth separating: the things that change every day do not belong on the printed card at all.
A lunch special, a soup of the day, a Friday fish menu — printing them means reprinting constantly, so most restaurants end up with a handwritten board and a photo posted somewhere. Daily offers are scheduled by date or weekday and switch themselves on, appearing on the digital menu and on the website widget without anyone touching the main menu.
The standing menu stays stable and printed. The moving parts stay digital. That division is most of the problem solved.
The test
Take your printed menu and your till. Check five prices at random.
If all five match, you are in a minority and your process is working. If one does not, the question is not whether to reprint. It is why reprinting is hard enough that you did not.
Restaurant Hub is built on the idea that a restaurant should enter its menu once. The printed card is one of the outputs, not a separate document with its own life.
