When you disable a sold-out item in your POS, a connected ordering channel may hide it, mark it unavailable, or continue accepting it until an update arrives. The result depends on which system controls availability, how the connection handles updates, and whether that particular item and channel are included.
Do not assume a successful item mapping means the sold-out status travels too. Mapping establishes which item is which; availability propagation determines whether a change reaches each ordering screen and when. Before relying on a connection during service, run an 86-and-restore test for an item and a dependent choice, then record what each system actually shows.
Identify the control point before you test
Start with one location, one item, and the channels where guests can order it. List the systems between the person making the change and the guest-facing menu: your POS, any integration or order-management software, and each ordering channel. Include a kiosk or QR menu if that location uses one. A channel can have its own availability setting even when it receives other menu data from the POS.
Ask the provider which system is the source of the availability change for each connection. Can a manager disable and restore an item in the POS, or must staff do it somewhere else? Does the connection send both changes, only the sold-out change, or neither? If two systems can make changes, ask which setting wins when they disagree.
Write down the exact item name and location in each system. Also identify a modifier or dependent choice, such as a side that can be selected with an entree. A side appearing in several dishes deserves special attention: disabling it for one item may not tell you what happens elsewhere.
Availability can be scheduled, manually changed, or affected by another setting. Before the test, agree on a known starting state: the item and choice are available in the relevant systems. Note any scheduled menu change that could interfere. If you cannot see or control one channel, have someone with the right access observe it.
Review the actual connections for your location rather than treating a provider's integration list as a promise for every setup. Fleksa's restaurant integrations directory distinguishes live connections from those available on request. Ask whether your specific POS, ordering channels, location, and availability updates are supported together.
Test one item and one dependent choice
Run the initial check in a provider-approved test environment or with a safely isolated test item. Confirm that the exercise cannot create a real card charge, guest message, or courier dispatch. If you cannot isolate the change, agree on a safe procedure with the providers before touching a live menu. A simulated check is not the same as a live service pilot.
Use a small sequence that makes the cause of each observation clear:
- Confirm the starting state. Find the parent item and its dependent choice in the control system and on every test ordering screen. Record whether each can be selected.
- 86 the parent item. Disable it at the agreed control point. Record the time, then check each connected screen separately. Note whether the item disappears, is labeled unavailable, or remains selectable.
- Attempt a safe simulated selection. If the item remains visible, check whether the test flow allows it to be selected. Do not place a real order to find out. Record what happens at the last safe step.
- Restore the parent. Wait until the relevant screens show it available again before changing the dependent choice.
- 86 the choice. Check whether the parent remains orderable and whether the unavailable choice can still be selected. If the choice appears under another parent, check that use as well.
A hidden item and a visible item that cannot be selected can both prevent an order, but they create different guest experiences. More important, a parent that remains orderable while an unavailable required choice is still selectable needs a clear resolution. Ask the provider whether the guest should see an alternative, be blocked, or encounter another supported behavior. Do not assume the system will substitute a choice for you.
Where a safe test order is supported, use a unique identifier and follow it to the POS or kitchen result. Check the selected modifier and total. This is a separate check from watching a menu update: a screen can look correct while the order data reaches the kitchen incorrectly.
Measure the delay and decide what counts as a pass
Use the same clock for the change and observations, or make sure observers' clocks agree. Record the time the control system accepts the change, not just the time someone begins clicking. For each channel, record the first time an observer sees the expected result. If you check at intervals, the exact update could have occurred between checks; note the last time it was wrong as well as the first time it was right.
The following is a hypothetical simulated test for a lunch bowl and its rice choice. The team checks every minute. Its agreed acceptance rule is that each tested screen must block the disabled selection within three minutes and show it selectable again within three minutes of restoration. The rule is an operational target for this example, not a guarantee from a provider.
| Action or observation | Time | Observed result | Decision |
|---|---|---|---|
| Disable lunch bowl in control system | 10:00 | Change accepted | Start parent-item clock |
| Direct ordering screen | 10:02 | Bowl blocked; still selectable at 10:01 | Pass: observed within 2 minutes |
| Second connected channel | 10:04 | Bowl blocked; still selectable at 10:03 | Fail: exceeds 3-minute target |
| Restore bowl | 10:05 | Change accepted | Start restore clock |
| Both ordering screens | 10:07 | Bowl selectable on both | Pass: observed within 2 minutes |
| Disable rice choice | 10:08 | Change accepted; bowl remains available | Start choice clock |
| Both ordering screens | 10:10 | Rice blocked on both; bowl selectable | Pass: observed within 2 minutes |
| Restore rice choice | 10:11 | Change accepted | Start restore clock |
| Both ordering screens | 10:13 | Rice selectable on both | Pass: observed within 2 minutes |
The table shows why the team should not call the connection a full pass: the second channel took at least until the 10:04 observation to show the parent as blocked, outside the agreed target. The rice result does not erase that failure. The team could ask whether the delay is expected, whether a setting needs correction, and how staff should handle that channel until it meets the target.
Set your own target around service needs. A restaurant that regularly sells its last portion during a rush may need a tighter response than one disabling a dish before opening. Ask the provider what update timing it expects, whether it can report a failed change, and how staff can retry or correct it. If a connection is unavailable, find out whether changes queue, must be reentered, or need a manual channel update. Treat those as questions to resolve, not assumed safeguards.
Restore availability and reconcile every channel
Restoration deserves its own check. A system that receives an 86 update may not restore the item on the same schedule or through the same control. Record the restore time and inspect each channel again. Check the parent and the choice separately, including any other menu item that uses that choice.
For each result, keep the location, item, modifier, control point, action time, last incorrect observation, first correct observation, and observer. Add a brief outcome: passed, failed, or not tested. If a channel behaves differently from the agreed acceptance rule, record the owner of the next action and the temporary staff procedure. Do not mark an unobserved channel as available just because another one updated.
Before a real service pilot, resolve failed simulated checks with the provider or document a workable manual process. For example, a manager might need to disable an item directly in a lagging channel and verify it there. Confirm who has access and who will restore it. During a live pilot, use an agreed procedure for actual service and monitor the results; unlike a simulation, live orders and guest communications may be real.
If a channel is intentionally unsupported, document that limitation rather than counting it as a failed supported connection. Then decide whether the manual work is acceptable at your order volume. Ask about the scope of any quote, including setup or integration charges, and which operational costs fall outside it. Your goal is a process staff can follow when the last portion sells, not simply a menu that looked right once.
For more context on where connections can sit, read the guide to direct POS integration and middleware. When comparing a restaurant POS with restaurant online ordering, bring your channel list, required update times, and the item-and-modifier test. Request a Fleksa demo and ask the team to walk through those requirements and test cases for your location.
Frequently asked questions
Does disabling an item in the POS remove it everywhere?
Not necessarily. Each connection may handle availability differently, and a channel may update later or require a separate change. Check every channel where the item can be ordered.
Should I test modifiers as well as menu items?
Yes. Test a dependent choice separately from its parent, especially when it is required or appears under several items. Confirm whether guests can still select the parent and whether the unavailable choice is blocked.
What should staff do if an item stays available online?
Follow the agreed fallback for that channel, such as a manual disable, and verify the result. Assign someone to investigate the failed update and restore the item in each affected system when it is back.
