Sold-out items can remain orderable when a restaurant changes availability in its internal system but the intended delivery channel does not receive, accept or display the update. Begin by identifying the authoritative item status, affected branch and specific marketplace. Then trace publication acknowledgments and check the customer-facing listing before assuming a real-time sync exists.
Why sold-out items remain available on delivery apps
Restaurant menu sync issues are not always inventory-system failures. One brand can intentionally offer different menus by city, branch, channel or daypart. An item can also appear live because of a channel override, a product-ID mismatch or an update that was saved locally but never published.
LYNNC’s menu management guide covers the wider catalog structure. This article narrows the question to a sold-out availability incident and its testable recovery workflow. It does not imply that LYNNC or every POS offers live stock synchronization.
Operational signals
- Guests repeatedly order a product the kitchen has marked unavailable.
- Only one delivery app or one branch still lists the item; other destinations correctly hide it.
- A product disappears from the parent menu but a combo or modifier still exposes it.
- A staff member turns an item back on for a different branch and accidentally changes the wrong location.
- A scheduled menu refresh reactivates an older item state.
The immediate priority is to prevent more unfulfillable orders using the affected channel’s approved controls while investigating the root cause. Do not wait for a speculative global sync repair if a supported per-item override or temporary pause is available.
Diagnose what changed, where and when
Create one incident record per affected item × branch × channel combination. Restaurant staff should capture a timestamped screenshot of the actual customer-facing listing and the internal intended state. Saving a new value inside the POS or CMS does not prove that the marketplace applied it.
- Item identity: internal product ID, external menu item ID, any bundle/variant ID and relevant modifier group.
- Location: exact branch and marketplace storefront ID; avoid relying only on display names.
- Desired state: available, unavailable, temporarily paused or scheduled; note whether the state is inherited or overridden.
- Publication trail: last change user, timestamp, sync job or API event reference, response and error if available.
- Observed state: actual orderability on the customer-facing marketplace, checked for the correct delivery address and location.
- Owner: who updates the source catalog, who manages the channel override, and who approves restoration.
If you lack a returned publication status, label the update “unverified,” not “successful.” Test one product first; a mass republish can unintentionally replace legitimate location-level differences.
Step-by-step fix: source status, publication and overrides
- Contain the incident. Where supported, pause the affected product on the channel or use an approved assisted-order procedure to avoid further unavailable orders.
- Identify the system of record. Establish whether the POS, central menu service or marketplace override owns the intended availability for this item.
- Check product matching. Compare stable item IDs and variant/bundle mappings across the source, connector and destination.
- Review branch rules. Confirm that the availability change targets the intended kitchen and storefront, not a brand-wide menu by mistake.
- Inspect publication logs. Look for rejected changes, delayed jobs, missing authorization or unsupported availability fields.
- Check channel overrides. A marketplace may retain locally edited hours, products or availability; establish which settings take precedence in the actual integration.
- Re-publish narrowly. Correct one affected item and confirm an acknowledgment; retry only through a supported mechanism.
- Verify as a guest. Check the destination listing and attempted item selection for the appropriate branch and time window.
- Restore carefully. When the item is back in stock, repeat verification after re-enabling, and review any related modifiers or bundles.
A correct result for a product in Riyadh does not prove the same mapping is correct in Jeddah. Verify destination behavior wherever the catalog has independent pricing, availability or published menus.
Out-of-stock sync audit sheet
Use the following matrix as a quality-assurance worksheet. Populate the last column from real test evidence. A green internal toggle is insufficient without a destination check.
| Test | Expected outcome | Evidence / failure action |
|---|---|---|
| Single item set unavailable | Item cannot be ordered at correct storefront | Guest-facing test; recheck channel override |
| Wrong-branch safeguard | Other branch stays available if intentionally stocked | Side-by-side branch listing |
| Modifier stock-out | Unavailable modifier is not offered where supported | Modifier-level test and mapping review |
| Combo references sold-out item | Bundle cannot create an unfulfillable order | Bundle and child-item test |
| Channel rejects publication | Error recorded and alert assigned | Publication response and owner |
| Reconnect after outage | Latest intended state is reconciled | Resync trace and destination check |
| Scheduled menu switch | Availability does not revert unexpectedly | Test at relevant daypart boundary |
| Restock item | Item becomes orderable only after approved release | Supervisor approval plus live check |
Hypothetical multi-branch example
Hypothetical example: a Jeddah restaurant marks a seasonal dessert unavailable at 17:30. The same brand has a Riyadh branch where the dessert remains available. At 18:00, a customer in Jeddah still sees the dessert on one delivery app, while the restaurant’s central menu shows “off.”
The menu owner checks the item identifiers and discovers that the Jeddah storefront has a channel-level setting different from the central menu. The branch uses the marketplace’s approved temporary unavailability control, then investigates the connector’s publication scope. Once the correction is accepted, a staff member verifies the actual Jeddah listing. The team leaves Riyadh unchanged.
This illustrates careful isolation by location and channel. It does not demonstrate a specific vendor feature or guarantee that a connector will propagate updates immediately.
What to validate with integration suppliers
Ask vendors to show not just a menu sync screen, but the exact availability field, direction, override precedence and publication acknowledgment for the marketplaces you operate. Order flow and menu flow may have different entitlements.
| Question | Required demonstration | Risk if omitted |
|---|---|---|
| Where is source availability set? | Named system of record and responsible role | Conflicting toggles |
| Is stock status supported? | Field-by-channel scope with exclusions | False “real-time” assumptions |
| Do branch-specific exceptions survive? | Two-branch scenario | Accidental brand-wide outage |
| How are rejections exposed? | Failed publication example | Silent channel mismatch |
| What overrides are possible? | Approved priority rules and audit | Channel overwrites source |
| How do staff restore an item? | Re-enable plus destination verification | Premature guest orders |
The API integration article describes why publishing and confirmation must be separate concepts. For software buyers, LYNNC’s Integrations page is the appropriate place to request a connector-specific scope check, not to assume instant inventory synchronization.
Monitor mismatch frequency and acceptance tests
Availability mismatch rate = verified item-branch-channel observations where the marketplace offers an item that should be unavailable divided by all valid availability checks. Separate those from orders that were placed before the stock-out event or while an approved delay window was still in effect.
- Audit a rotating sample of high-demand, frequently sold-out products across the main delivery channels.
- Capture time from approved source change to confirmed destination state for the actual integration; do not invent a universal SLA.
- Record cancellations and customer contacts attributable to sold-out listings, not all cancellations.
- Create an escalation queue for changes with missing acknowledgments or stale destination availability.
- Re-test after mapping changes, new branches, channel promotions and menu imports.
Before rollout, verify a real sold-out and restock cycle on every relevant channel, including branch-specific and bundle exceptions. An accepted sync API response is not the final acceptance test if the actual ordering interface remains wrong.
Frequently Asked Questions
Why are sold-out items still available on delivery apps?
The availability change may have been stored internally without being published or accepted by the marketplace. Incorrect item mapping, location selection, scheduled changes and channel-level overrides can also explain the mismatch.
How should an operator check publication and channel overrides?
Trace the original item ID and branch ID, inspect the last publication event and compare its acknowledgment with the actual storefront listing. Determine which system wins when internal availability and a channel override conflict.
What should a Saudi restaurant test in the demo?
Test unavailable and restored states for two branches, including a modifier or bundle that refers to the affected item. Ask for a failed-publication demonstration and the approved workaround.
Which metric proves menu availability is improving?
Use verified availability mismatch frequency and the time needed to correct confirmed mismatches. Supplement these with cancellations attributable to an item that was incorrectly left orderable.
Decision: Choose a supported menu integration only after confirming branch and channel behavior in real listings. Request a workflow fit demo for the supported availability fields and exception process in your setup.
