A digital menu price update is complete only when the price a guest sees matches the price the team is prepared to honour. Editing one item in an admin screen is not enough if a saved link, a related guest choice or a location page still shows yesterday’s information.
Use this checklist for a permanent price change, a time-limited approved price change or a short-term correction. It is an operational guide, not legal advice: pricing-display requirements can vary by location and service model.
What belongs in a digital menu price update?
Start with the guest decision, not the database field. A guest needs to know what the item costs, which choices affect that price and whether the menu applies to the location and service they are about to use.
| Check | Confirm before publishing | Named owner |
|---|---|---|
| Scope | Item, location, service period and effective time | Manager who approved the change |
| Price path | Every guest choice that changes the same total | Menu editor |
| Guest display | Mobile menu, QR destination and any live shared link | Shift lead or designated tester |
| Team handoff | What changed, when it starts and how to handle a mismatch | Shift manager |
| Follow-up | Where the change and any correction are recorded | Menu owner |
This prevents a failure in which the base price is corrected while an add-on, special version or other guest path keeps the old value.
1. Freeze the scope before anyone edits
Write one short change note before opening the menu. Include the item name, the affected location, the first service that uses the new price and every choice that changes with it. If a price applies only during one service period, say that plainly instead of leaving the next person to infer it.
Do not use screenshots or an old staff message as the source of truth. Ask the approver to confirm the current change once, then let the menu editor work from that confirmation. A clear scope makes it easier to reverse a mistake and to explain an exception without exposing guest information.
2. Update the full price path, not only the headline item
Open the item as a guest would. Check the base selection and every linked guest choice that changes the total. A guest does not experience your content model; they experience the final choice they can make on a phone.
Keep labels explicit. If a choice has a different price, name the choice and make its difference visible where the choice is made. Avoid burying a condition in an image, a vague note or a staff-only instruction. The W3C guidance on clear web writing is useful here: specific headings and descriptive labels help people scan the decision quickly.
3. Check the guest-facing menu on a phone
Publish or preview the approved update through your normal process. Then leave the staff account and test the public route on a phone.
- Scan the table, window or takeout QR code that guests actually use.
- Open the item and its price-changing choices.
- Confirm the correct location and service context.
- Read the displayed price without relying on internal knowledge.
- Confirm that the item name and price are visible in the actual menu layout.
4. Brief the team before the new price is in front of guests
The handoff can be one minute. Tell the host, server or counter lead which item changed, when the new price starts and where they should verify it. Do not ask the team to remember a second, unofficial price list.
If a guest asks through a phone call, a message or at the door, the response should begin from the verified public menu. That keeps a quick answer from creating a new, untracked version of the price. Record only the operational mismatch, never the guest’s contact details in a price-update note.
5. Give the team a safe response for a mismatch
Even a careful update can meet an old bookmark, a cached page or a printed item. Decide in advance who can make the service decision and how the team should escalate it. The first response should acknowledge the mismatch, verify the current guest-facing page and explain the next step without arguing about what the guest saw.
After service, capture the cause in a short internal note: which path was stale, who fixed it and whether another menu surface needs review. That is enough to prevent repetition. It does not require copying an order, phone number or guest name.
6. Keep price work inside the broader guest-content check
Price accuracy is one part of a useful public menu. Hours, location and the next action also shape whether a guest arrives with the right expectation. Use the restaurant mini-site content checklist when a menu change may affect the rest of that visit.
If the same public journey also includes a waitlist, keep its entry clear through restaurant waitlist software and the QR-code waitlist page. Verify current product information on the pricing page. StoveOps can provide a public mini-site with a digital menu and waitlist form; the restaurant should still own the operational review before publishing any guest-facing change.
A short pre-service sign-off
Before the next busy service, the owner of the change should be able to answer yes to each question:
- Is the approved price present on every guest choice that depends on it?
- Did someone test the public QR code or link from a phone?
- Does the team know when the change begins and where to verify it?
- Is there one approved path for handling an older displayed price?
- Is the menu still clear and readable without staff explanation?
That sign-off is small, but it protects the guest conversation at the moment it matters. A digital menu should help someone decide, not send them to the host stand to reconcile two versions of the same price.