Menu Version Control: Keeping QR, Print and Delivery Menus in Sync

Where menus drift apart

Drift starts with a small change. A dish sells out and the kitchen tells the floor, but the QR page still lists it. A price changes in the till but not on the printed copy in the drawer. A delivery listing keeps an old item because nobody has the login. A seasonal special stays on the website three weeks after it ended.

Each of those is a five-minute fix at the time. Left alone, they compound into a menu that guests cannot trust, and a floor team that answers the same question five times a night.

Two structural causes sit underneath most drift: nobody owns the menu as a whole, and the same content is maintained in more than one place by hand. Fix the ownership and the duplication, and the small fixes become manageable.

One master, one owner, one change log

Choose the version that is authoritative. For most restaurants, the hosted menu is the right master: it is editable, it is dated, and it can be read from anywhere. The printed menu and the delivery listing become copies of it.

• **One master:** the hosted menu, edited first, so it is never behind the conversation on the floor.
• **One owner:** a named person, with a named backup for days off. The owner is responsible for making the change in the master and for checking the copies.
• **One change log:** a single page or shared document with date, what changed, who made the change, and which channels were updated. The log is what turns a series of small decisions into a history you can trust — when a guest asks about a price they saw last month, it answers the question in seconds.

A pre-service channel check

Once a week, or after any menu change, run a short check across the channels you actually use. It takes a few minutes if you work in a fixed order.

Record the result with a date and a name. An unchecked channel is an assumption, and assumptions are what drift.

• **Master menu:** is it the version you intend guests to see, with the correct date?
• **QR menu:** scan the code on a phone, not just the page in a browser. Does the destination match the master?
• **Printed copies:** are the copies in service the current edition? Remove old copies from the drawer, the host stand and the server station.
• **Delivery listings:** check each listing, including duplicates for the same brand, for price, availability and item names.
• **Website menu page:** check the page and any ordering widget, which is often a separate system.
• **Specials boards and signage:** confirm nothing from a previous period is still displayed.

What to do when a channel lags

Some channels cannot be updated immediately. A delivery platform may take a day to reflect a change; a printed menu may have to last until the next planned run.

Decide in advance what you will do in those cases. For a sold-out item, the fastest safe answer is to mark it unavailable in the channel you control and give the floor a script for the channels you do not. For a price change, a printed insert or a dated supplement is better than a sticker over the old number, because a sticker draws the eye to the change.

What you should never do is leave a channel quietly wrong and hope nobody orders from it. A guest who orders a dish you cannot make, or arrives expecting a price you no longer charge, has a worse experience than a guest who sees an honest temporary note.

Dated print versions and rollback

Print versions need dates. Add an edition date in a small, consistent place on every printed menu, and keep one copy of each edition on file. Two things become possible once you do that.

First, you can tell which guests are reading which edition, which is useful when a question about an old price comes up. Second, you can roll back. If a new menu causes problems — a section that does not work, a dish that is not ready, a price that was wrong — you can return to the previous edition deliberately rather than trying to reconstruct it from memory.

Keep the rollback simple: the previous edition, the previous prices and the previous descriptions should be recoverable in one place. If your master menu has a version history, that is the place.

Worked example: a Friday check that finds two problems

The details below are illustrative.

A restaurant changes two prices and removes one dish on a Wednesday. The manager updates the master menu and the QR page. On Friday, before service, the weekly channel check finds two problems: the delivery listing still shows the removed dish as available, and one printed copy in the server station is the previous edition.

The removed dish is marked unavailable in the delivery listing, which takes a few minutes once the login is found. The old printed copy is removed from the station and replaced with the current edition; the remaining copies in the drawer are checked and dated.

The check takes under ten minutes and prevents two predictable failures: an order for a dish the kitchen cannot make, and a guest reading a price that no longer exists. The log records the change, the date and the two channels that had drifted.

Building the habit

Three habits keep version control from becoming a project.

First, make the change in the master before you tell anyone about it, so the master is never behind. Second, run the channel check on a fixed day, so it does not depend on someone remembering. Third, keep the change log where the team can see it, not in a private folder.

When the master is hosted, the MenuCrafters AI menu builder keeps the menu you edit as the source for the hosted QR page and the print-ready PDF, which removes one copy from the chain: the printed menu becomes an export of the master rather than a document maintained by hand.

Limitations and assumptions

This discipline assumes you can edit at least one channel directly and that you know who owns the menu. It assumes you have access to your delivery listings; where a platform controls the listing or updates slowly, you can only control your own channels and your floor script. It cannot eliminate human error, and it does not cover every case — a guest reading a cached version of a web page, a third-party site that copied your menu months ago, or a photo of an old menu posted online. The check is a routine, and routines lapse when nobody owns them, which is why the named owner and the log matter more than the checklist itself.