A restaurant digital menu audit is a scheduled check of the public menu a guest can actually open. Review item names, descriptions, choices, availability, prices, location context, links, and the route from a QR code or shared link. Test it on a phone, assign corrections to named owners, then confirm the published version before the next service.
Start with the guest-facing route
An audit does not start in the menu editor. Start with the QR code on a table, the link in a message, or the address a host gives a guest. Use an ordinary phone without a staff bookmark. That is where an old destination, a wrong location, or an unclear label becomes visible.
| Check | Confirm before service | Named owner |
|---|---|---|
| Arrival | The public page identifies the restaurant and the intended location | Shift lead |
| Readability | Menu text, choices, and instructions remain easy to read on a phone | Menu owner |
| Choice | A guest can understand what changes the item, not just ask staff to translate it | Menu owner |
| Current state | Prices, availability, and daily information match the approved source | Kitchen and floor lead |
| Route | QR code and shared link reach the same current public menu | Tester |
| Handoff | The next shift knows where to verify the published version | Shift lead |
The QR code placement guide helps when the sign itself needs review. This audit uses that route to test the complete guest decision, rather than treating a readable code as proof that the menu behind it is correct.
A restaurant public mini-site can carry both the digital menu and a waitlist form. When the audit changes the wording or destination of that public entry, review the matching restaurant waitlist software route as well, so the guest does not receive two conflicting instructions.
Compare the published menu with one approved source
Choose one source for the audit before anyone starts editing. It might be the chef-approved menu file, a service sheet, or a named owner who resolves changes. The point is not to create a second menu. It is to make every public detail answerable by one current source.
Review an item from top to bottom: name, description, visible price, choices, availability wording, and any instruction that changes the guest’s decision. If a label such as “choose a side” hides a required step, the guest should not need staff to discover it. The W3C guidance on labels and instructions is a useful review question: can a person understand the action before taking it?
For visual review, check contrast in the state a guest sees, including unavailable notes and buttons, not only the default design. The W3C contrast guidance explains why text that disappears into a photo or background is a decision problem, not just a design detail. Use the menu modifier guide when the issue is a missing or confusing option.
Send each finding to the right workflow
A monthly audit should not produce a vague request to “fix the menu.” Name the finding and route it to the narrowest useful workflow. That makes the correction faster and makes the retest unambiguous.
| Finding | First action | Related workflow |
|---|---|---|
| Visible price differs from the approved source | Stop guessing and confirm the current value with its owner | Price update checklist |
| An item cannot be served | Mark or remove it through the agreed service process | Sold-out item process |
| A choice is missing or unclear | Rewrite the choice so the guest can decide before asking | Digital menu modifier guide |
| QR code reaches the wrong route | Test the sign, destination, and placement separately | QR code placement guide |
| Hours, menu, and guest route disagree | Review the wider public entry point | Mini-site content checklist |
Do not record a guest’s name, phone number, or order detail to explain a menu defect. The page, observed issue, owner, time of retest, and outcome are enough for a service-quality note.
Retest the public version, then brief the next shift
With StoveOps, a restaurant’s public mini-site can carry its digital menu, and a QR code can bring a guest to that mini-site. Saving an active-menu edit starts an automatic update, but the team should still open the published route before treating the work as finished. The restaurant digital menu software page describes that public route.
Use the pricing page for current plan scope instead of copying plan details into the audit card. The card should stay focused on the guest-facing check and link to the maintained source when a plan question arises.
Retest from the same entry point that exposed the issue. Confirm the restaurant, location, language, item details, and next action. Then give the next shift a short handoff: what changed, who approved it, where the live version was checked, and what to do if it returns. A correction that only one person can find is not yet a reliable menu.
Copy this monthly sign-off card
- Did we open the public menu through the route guests use?
- Does every reviewed item show its current name, description, choice, price, and availability?
- Can a guest read the important text and understand the next action on a phone?
- Does one approved source resolve each discrepancy?
- Did we retest every correction after publishing?
- Does the next shift know the current public route and its owner?
The goal is not to turn menu review into paperwork. It is to stop small content mismatches from becoming a table-side explanation during service.
If the same audit finding appears at more than one restaurant, send it through the multi-location digital menu governance guide so the group can improve the shared rule without replacing a local service decision.