After changing website or ordering providers, check every menu page and ordering action against the destination it should open. Follow each path as a guest would: choose the location and service mode, select an item, and review the checkout before placing an order. A menu that looks correct is not enough if its button still points to the old provider or the wrong restaurant.
Give each path a pass, fail, or not-applicable result. Fix failures, repeat the same checks, and keep a record of who approved the final destination. You do not need to place a real order to inspect most of the handoff.
Inventory every menu page and action
Start with a list of the pages guests can reach, not just the main menu linked in the navigation. Include location pages, separate lunch or catering menus, mobile menu pages, downloadable menus, and pages linked from QR codes. A page with no obvious order button may still contain a linked item, banner, or footer action.
For each page, record its address and every action a guest can take. Note the button text, where the link currently goes, and where it should go after the change. Include actions such as Order Now, pickup, delivery, and individual item links. If a PDF cannot be edited directly, record the location of the source file and who can replace it.
Ask the website administrator for the page and link inventory. Ask the ordering provider for the intended ordering addresses, location identifiers, and service-mode setup. The restaurant manager should confirm which locations and services are actually operating, along with current menu prices and availability. If another agency manages QR codes or printed material, include that person in the review.
Do not assume that one working button proves the rest work. A shared header may use one link while a location page has its own. A mobile menu can also present a different action from the desktop version. Check both layouts and make a note of any path that opens a new tab or redirects through an intermediate page.
Access matters when it is time to make corrections. Confirm who can edit the restaurant website, who controls the domain, and who can change the ordering configuration. The domain ownership guide can help frame that conversation without turning this handoff check into a full website migration project.
Test each location and service mode
Build a separate test path for each meaningful combination of menu page, location, and service mode. If a location offers pickup but not delivery, mark delivery not applicable only after the manager confirms that arrangement. A delivery button that quietly sends guests to pickup is a failure, not an acceptable substitute.
For each applicable path, open the menu as a guest and follow the action. Check the destination name, address, and selected service mode. If the guest must choose a location, confirm that the correct choice is available and clearly labeled. If the link is supposed to preselect a location or mode, check that it does so. Then select a representative item and proceed far enough to inspect the cart and checkout details.
Use a private browser window or a fresh session for a repeat check. A remembered location, old cart, or prior login can hide a bad link. Repeat on a phone and a desktop browser, especially where the site uses different navigation. Record the device and browser with any failure so the person fixing it can reproduce the problem.
The following is a hypothetical example. A restaurant has two locations, Oak and Pine. Oak offers pickup and delivery; Pine offers pickup only. The owner expects each location page to lead guests to that location, while a general menu may ask guests to select one. These are assumptions for the check, not claims about any provider.
Use the matrix below as an acceptance record. Each row represents a distinct guest path; add rows for other pages, devices, and actions. The observed result and decision show what the owner should do, rather than treating a click alone as success.
| Guest path | Expected destination | Observed result | Decision |
|---|---|---|---|
| Oak menu, pickup button | Oak ordering, pickup selected | Oak pickup cart opens | Pass after item and price check |
| Oak menu, delivery button | Oak ordering, delivery selected | Old ordering page opens | Fail; replace link and retest |
| Pine menu, pickup button | Pine ordering, pickup selected | Oak pickup cart opens | Fail; correct location mapping |
| Pine menu, delivery | No delivery action | No delivery button shown | Not applicable; manager confirms service |
| General menu, order button | Current ordering page with location choice | Both locations offered | Check each available choice before passing |
A general location selector can be useful, but it adds a decision for the guest. A location-specific link removes that step only if it reliably selects the right location and mode. Choose the expected behavior deliberately, then test against it.
Compare menu prices with the cart and checkout
A correct destination can still create confusion if the website menu and cart disagree. Compare a small set of representative items for every location and service mode: an ordinary item, an item with options, and an item that is unavailable or restricted by time. Check the item name, base price, option price, and availability. Add more items where menus differ substantially.
In a separate hypothetical price check, a menu shows a sandwich at $12 and an optional side at $3. The cart should show $15 for that selection before any separately displayed fees or taxes. If checkout adds a $2 delivery fee, the visible subtotal plus that fee is $17 before taxes or any other charges. This example includes the item, option, and stated delivery fee; it excludes taxes and any other charges. It is not an all-in quote or a statement of any provider's fees.
If the cart shows $16 for the item and side before fees, record the mismatch. Ask the manager which amount is current, then correct either the website menu or ordering catalog. Do not simply change the website to match checkout without confirming the intended price. Also check whether the displayed menu describes the same size and included options as the cart.
For availability, try an item that the manager expects to be unavailable at the selected location or time. The acceptance question is whether the guest gets an accurate, understandable result before attempting to order. If hours, scheduling, or service areas affect what appears, document the conditions under which you checked.
Stop before submitting an order or entering real payment details. A simulated check must not trigger a real payment, guest message, or courier dispatch. Ask the provider whether a safe test environment is available and what actions it prevents. If the final submission and fulfillment steps need validation, arrange a separately authorized live service pilot with staff, the provider, and any delivery partner. Agree on the charges and handling in advance; do not treat that pilot as a simulation.
Correct stale links and retest before sign-off
Give every failure an owner. A website editor may need to replace a button URL, while the ordering provider may need to correct a location or service-mode setting. A printed QR code can require a different remedy from a website button. Record the requested change, the person responsible, and the date it was made.
When a link opens the old ordering destination, identify the source of the link before changing it. The visible button may point directly to the old address, or an intermediate redirect may send guests there. Ask whoever controls that redirect to update it and explain which pages or codes depend on it. Keep the old destination in the record so the retest can confirm it no longer appears on that path.
Retest the complete journey, not just the edited button. Open the original menu page in a fresh session, follow the action, verify location and mode, and inspect an item in the cart. Repeat on the affected device layouts. Then check related actions that share the same template or redirect; a change intended for Oak should not send Pine guests to Oak.
Mark a row as passed only when the destination and the relevant cart checks meet the agreed expectation. Keep failed rows open and use not applicable only for a confirmed absence of service. The manager can sign off when applicable rows pass, or make a documented decision about any remaining issue and its owner. Monitor the paths again after launch and when menus, locations, hours, or links change. No prelaunch checklist can guarantee that a later change will not introduce a problem.
Use this checklist on your current setup, then ask Fleksa about online ordering and verified US availability if relevant. Bring your matrix and ask how an existing website would link to the intended location and service mode.
Frequently asked questions
How many menu links should I check?
Check every distinct menu action and destination, including location-specific buttons, mobile navigation, downloads, and QR-code paths. A shared template can reduce editing work, but confirm that each location reaches its intended destination.
Do I have to place an order to check the handoff?
No. You can usually inspect the destination, location, service mode, item, and cart without submitting. Arrange a separately authorized live pilot if you need to verify what happens after submission.
What if the menu price differs from checkout?
Record the item, options, location, mode, and both amounts. Ask the manager which price is intended, correct the appropriate source, and repeat the path through the cart.
