To confirm a menu edit reached every intended delivery channel, make a list of changes and destinations, publish them, then compare each channel’s status with what a customer can actually see. Record the result by location and channel. An update is complete only when every intended destination is verified or an unresolved exception has an owner and a next decision.
A successful save in your menu editor is a useful first step, but it does not answer the buyer’s question: can a guest at the right location see and order the right item? The workflow below gives your team a repeatable way to find out.
Separate product sync from menu publishing
A product sync moves or aligns item information between systems. A menu publish makes a menu version available on a destination. Depending on the setup, those steps may happen together, separately, or partly through manual work. Do not assume that an item appearing in a POS means it has reached every marketplace storefront.
Start with the path your menu takes. Does the POS hold the main menu? Does an integration tool prepare the channel menu? Does a marketplace require a separate publish or approval step? Ask the vendor to draw the path for each of your locations and destinations, including any steps performed in another dashboard.
For example, an owner might have a downtown location selling through direct ordering and two marketplaces. A second location might use only direct ordering and one marketplace. Those are different destination lists, even if both locations start with the same menu. A shared item name does not prove that prices, modifiers, availability, and images are shared too.
When comparing restaurant integrations, identify the exact channel, location, and POS combination rather than asking whether a vendor supports “delivery apps” in general. Fleksa’s directory distinguishes live connections from those available on request. Ask which connection and publishing actions are available for your setup, and which tasks your staff would still perform manually.
List changes and their intended destinations
Before publishing, write down what changed and where each change should appear. Include the item name or identifier, the location, the expected value, and the intended channels. For a modifier, record both the choice and any price attached to it. For an unavailable item, specify whether guests should see it as unavailable or not see it at all.
Keep the scope small enough to check. If you update a category with many items, select a customer-facing sample that includes the kinds of changes you made: an item price, a modifier, an availability change, and an image if applicable. Also identify any high-risk item that deserves an individual check, such as one with a major price change. A sample can reveal errors, but it cannot prove every uninspected item is correct.
Use the following hypothetical log for one downtown location. The owner changed a bowl’s price, changed a modifier price, and made a soup unavailable. Direct ordering and two marketplace listings are intended destinations. The entries show a check after publishing, not a claim about any particular provider.
| Destination | Expected change | Observed result | Owner and next decision |
|---|---|---|---|
| Direct ordering | Bowl $14; avocado add-on $2; soup unavailable | All three match on the customer-facing menu | Manager records verified |
| Marketplace A | Same three changes | Prices match; soup still appears orderable | Manager checks publish status and decides whether to remove soup manually |
| Marketplace B | Same three changes | Publish pending; storefront not yet checked | Shift lead checks again at the agreed review time |
The log makes three different outcomes visible: verified, inconsistent, and still awaiting inspection. Neither of the last two should be marked complete just because the initial publish action was submitted. Add timestamps and a menu version or change reference in your working log so the next person knows which update is under review.
Ask a prospective vendor to demonstrate the same journey for your actual setup: edit an item, send it to the intended destination, and show where staff can see the result. Ask whether a single publish covers all destinations, whether prices and modifiers can differ by channel, and what happens when one destination rejects an update. For a specific marketplace, such as the Uber Eats integration, confirm the available workflow for your restaurant’s location rather than assuming every connection works alike.
Check status, then inspect what guests see
After publishing, review the status for each destination. A status may tell you that an update was submitted, is pending, succeeded, or needs attention. Ask what each status means: does “success” mean the destination received the data, or that its customer-facing menu has updated? A status without that definition is hard to use as an acceptance criterion.
Then inspect the storefront as a guest would. Choose the correct location and check the item in its category. Open the item detail, select the relevant modifier, and confirm the displayed price and availability. Check the ordering context too: a location, fulfillment option, or menu period can affect which menu a guest sees. If the expected menu is scheduled for later, record that and inspect it during the intended period.
Use a simple acceptance rule before you start: the displayed item, price, modifier, and availability must match the change list for that destination. Record the actual observation, not just “looks good.” If the bowl is $14 but the add-on still shows its old price, the item has not passed the complete check.
When an ordering test is needed, first ask the vendor for a simulation or supported test environment. A practice scenario must not charge a real card, send a guest message, or dispatch a courier. If the setup supports a safe simulated order, give it a unique test identifier and compare the selected item, modifiers, and total with the result received by the POS or kitchen. Confirm how exceptions can be tested without affecting live operations.
A simulation is not a live service pilot. If you later arrange a live pilot, agree on its scope, staff responsibilities, and controls with the providers involved before starting. Do not treat a simulated result as proof that every live order will work. For a deeper comparison of how data passes between systems, see the guide to direct POS integration and middleware.
Respond when a channel keeps the old menu
Give every unresolved entry one named role or person, a review time, and a decision to make. The owner of the issue does not have to fix the integration personally; they do need to make sure someone checks it and communicates the outcome. Keep the log free of private customer information.
For Marketplace A in the example, the manager should first compare the publish status and destination settings with the intended update. The next question is whether the soup can be made unavailable in that channel’s dashboard while the underlying issue is investigated. If a manual change is appropriate, record who made it and check the storefront again. Also note that a future sync might overwrite a manual edit; ask the provider how to prevent or resolve that conflict.
For Marketplace B, pending is not the same as failed or verified. The shift lead should check again at the agreed time and inspect the customer-facing menu once it is available. If it remains pending, escalate with the location, destination, change reference, timestamps, and observed status. Ask the provider what action is safe while the update is unresolved.
Decide in advance who can pause an affected listing or make a manual correction if the old menu creates an operational problem. If neither action is available, staff need a clear escalation path and a way to communicate the limitation internally. Do not assume a retry is harmless: ask whether republishing affects other menu edits or channel-specific settings.
Close an entry only after the owner records the final customer-facing result, or documents an accepted limitation and the person responsible for it. Review repeated failures separately from one-off delays. A pattern across the same channel, location, or type of modifier is useful information for the next vendor conversation.
Bring your channel list, POS details, and a few menu change cases to a Fleksa demo. Ask the team to walk through the available publishing and verification steps for your location using the restaurant POS system and relevant connections.
Frequently asked questions
Does a successful sync mean the menu is live everywhere?
Not necessarily. Ask what the sync status represents, then inspect each intended customer-facing destination. Record any destination that is still pending or does not match.
Do I need to inspect every menu item after every publish?
A targeted sample can check representative changes, but it does not prove uninspected items are correct. Check high-risk changes individually and expand the review when the update is broad or a mismatch appears.
What should I ask if a channel requires manual publishing?
Ask who performs the manual step, where they do it, how completion is confirmed, and whether a later sync can overwrite the change. Add that responsibility to the verification log.
