The menu owner should approve the price and effective time. A named editor should make the change, and a second person should verify the public menu and a sample cart. In a small restaurant, one person may fill more than one role, but each step still needs a name and a completion time.
That division answers the question guests care about: does the price they see match the price they are asked to pay? A dependable restaurant website menu update workflow also covers old links, location differences and a way to reverse a mistake.
Assign one source of truth and clear owners
Keep one approved menu record that staff can consult before changing any guest-facing page. It can be a shared document or spreadsheet if the restaurant controls who can edit it. List each item, description, price, location, service type and current status. Include hours as well, with a note about where guests should see them.
The source of truth is the approved record, not necessarily the page where an editor types the price. Your website menu, ordering catalog and linked files may each need separate edits. Ask whoever manages those systems which fields are shared and which must be updated independently.
Assign these responsibilities by name:
- Menu owner: Approves items, descriptions, prices and effective times. This might be the owner, general manager or another person with pricing authority.
- Editor: Makes the approved changes in each relevant system and records when they were published.
- Verifier: Checks the guest-facing result, including the ordering path where relevant, and reports any mismatch.
- Hours owner: Approves regular and special hours and identifies every place they need to be changed.
Set a backup for each role. If a manager is away on the day a seasonal menu starts, staff should know who can approve a correction. Limit editing access to people who need it, and keep a current list of who has access to the website and ordering tools.
For a restaurant with more than one location, identify whether the owner approves one shared menu or separate location menus. A single approval should not silently overwrite a local price or an item that only one kitchen serves.
Write the change request before editing
A useful request describes both the new value and its boundaries. “Raise the burger price Friday” leaves too much open: which burger, which Friday, which location and which ordering channel? Record the old and new values, the date, the local time and time zone, and whether the change covers pickup, delivery, dine-in or a combination.
Also list the affected public views. These might include a page on your restaurant website, a linked menu file and the item in online ordering. Add any other menu or ordering channels your restaurant uses. If a change applies to modifiers or combinations, name those too; a new base price does not explain whether an add-on price should change.
Here is a hypothetical request for one location. The restaurant raises a lunch sandwich from $12 to $13 at 11:00 a.m. local time on Tuesday. The new price applies to the public website menu and pickup ordering. Delivery pricing and other locations are outside this request. The owner approves the change, the editor publishes it, and a different staff member checks it.
Use a log like the one below for that request. The final column records the public result and rollback instruction, so the team can see both what happened and what to do if it went wrong.
| Change and scope | Owner and editor | Effective time | Public check and rollback |
|---|---|---|---|
| Lunch sandwich: $12 to $13; one location; website menu and pickup | Manager approves; website editor publishes | Tuesday, 11:00 a.m. local time | Verifier checks menu and pickup cart; record result and completion time. If wrong, restore $12 in affected views and notify manager. |
Before publishing, make the rollback more specific if the change touches several systems. Record the previous values and who can restore them. A rollback might mean reversing only the incorrect view, or restoring all affected views until the issue is understood. The menu owner should decide which response keeps the public information consistent.
Do not mark a request complete just because it was approved or entered. Give it a simple status such as requested, approved, published, verified or needs correction. If the price is scheduled for later, record when the editor will check that it actually appears; a scheduled change is not the same as a verified one.
Verify the public menu and a sample cart
At the effective time, the verifier should open the restaurant's public page as a guest would, rather than relying only on the editing screen. Check the correct location and service type. Read the item name, description and price together; a correct price beside the wrong item is still a failed check.
Then follow the relevant ordering path. For the hypothetical sandwich, select the same location and pickup service, add one sandwich and inspect the cart before checkout. The menu should show $13 and the sandwich line in the cart should also show $13. With no modifiers selected, the item subtotal is $13. This check concerns the item price only; it does not include fees or other checkout charges.
This is a simulated check, not a live order. Stop before placing an order or submitting payment. Do not send a guest message or dispatch a courier. If the system cannot show a cart without triggering a real transaction, ask the provider for a safe way to inspect the order price instead.
Use a phone as well as a computer when practical. Open the page from the same links a guest would use, including the menu link on the site. If an old price appears, refresh and try another browser or device to help distinguish a display issue from a published mismatch. Record what appeared, where it appeared and when it was checked.
Check a modifier or combination when the request affects one. For example, if a cheese add-on also changed, select it and compare the cart line with the approved base price and add-on price. Do not assume that updating the visible menu changed the ordering catalog, or that editing the base item changed every variation.
Ask the vendor how changes move between the website and ordering system, whether scheduling is available, and how staff can inspect the public result. If a provider offers a demonstration, bring a real change request and ask to see the steps without placing a real order.
Resolve conflicting versions and close the log
A restaurant can have a correct menu page and still send guests to an outdated file. Follow the links from the homepage, navigation and ordering button. Check any downloadable menu the restaurant controls and any other public menu locations on the change request. Update or remove stale linked versions where you have access. If a version is managed by someone else, assign a person to request the correction and track it separately.
When two views disagree, pause before guessing which one is right. Compare both with the approved record. Note the exact page or ordering path, location, service type, displayed price and time observed. The editor can then correct the affected view or carry out the agreed rollback. The verifier should repeat the public checks after the correction.
For the sandwich example, if the website shows $13 but the pickup cart still shows $12, the request remains open. The editor investigates the pickup item rather than assuming the website edit reached it. Once both views show the approved price, the verifier records the result and completion time. If the team restores the old price instead, record that outcome and agree on a new effective time before trying again.
Keep the log accessible to the people answering guest questions. A host or manager should be able to see whether a change is pending, completed or rolled back without searching through messages. Review recurring errors at a staff meeting: a missing location, a forgotten file link or an unclear approval can be fixed in the next request template.
Access matters when a correction is urgent. If an outside provider manages your site, agree on who can request an edit, expected response times and what happens after hours. Confirm who controls the domain and the website account; the guide to restaurant website domain ownership covers questions to ask.
For your next menu change, prepare one request and use it to walk through the full approval, publication and verification sequence. Review Fleksa's restaurant website page and, if it fits your restaurant, ask for a demonstration of how your team would make and check that change.
Frequently asked questions
Can the same person edit and verify a menu change?
Yes, especially in a small team. A second checker is useful when available. If one person does both, they should still check the public page and cart separately from the editing screen and record the result.
Should every price change have a log entry?
Yes. A short entry with the owner, scope, effective time, public check and rollback makes even a one-item change easier to verify and correct.
What if an old menu remains on a site we do not control?
Assign someone to contact the party that manages it, request an update or removal, and record the request. Keep the issue open until someone checks the public version again.
