To stop an unavailable item from reaching an online cart, staff need a fast way to mark it unavailable, a backup when the usual person is busy, and a way to check what guests actually see. The change also needs to protect carts that already contain the item. If the system cannot block those orders reliably, staff need a temporary fallback, such as pausing the affected ordering channel.
Before buying or changing your restaurant online ordering system, ask the vendor to demonstrate the full sequence: an item is visible, a guest adds it to a cart, staff mark it sold out, and the guest tries to check out. Then restore the item and check that only the intended options return. A menu label alone does not answer the buying question.
Give someone clear control of availability
Pick a primary person for availability changes on each shift. In a small restaurant, that might be the shift manager. In a busy kitchen, it could be the expediter, provided that person has permission and a device close enough to use during service. Name a backup who can act when the primary person is away from the screen.
Make the handoff simple: the kitchen calls out the exact item and affected options, the assigned person changes availability, and the person who made the change tells the kitchen when it is done. Until then, treat the item as still available online. If the restaurant also takes orders by phone or at the counter, tell those staff too.
Ask the vendor who can make the change, where they make it, and whether the backup needs a separate login. Check how many steps it takes on the device your team will actually use. A control buried behind several administrative screens may work in a demonstration but be awkward when a cook has just sold the last portion.
Specificity matters. A restaurant may be out of a large pizza crust but still able to make the small size, or out of one sauce but not the dish itself. Ask whether staff can disable an individual size, add-on, or combination without hiding unrelated choices. If the system only lets you remove the whole item, decide whether that limitation is acceptable before a busy shift.
Also agree on what happens when nobody can update the menu promptly. A manager might temporarily pause online ordering for the affected channel, if that control is available and the disruption is preferable to accepting orders the kitchen cannot fill. Keep the phone number or vendor support route handy; do not make a guest wait while the team searches for access.
Test the open menu and the existing cart
A guest can leave a menu open while deciding, and another can add an item to a cart before the kitchen runs out. Those are different situations from opening a fresh menu after an update. Ask for both to be demonstrated.
For a hypothetical simulation, suppose a restaurant has one mushroom pasta left. A test guest opens the menu and adds it to a cart. Staff then mark mushroom pasta unavailable. The test should stay in a sandbox or another safe practice setup: it must not charge a real card, send a guest message, or dispatch a courier.
First, look at the menu that was already open. Does the item disappear, show as unavailable, or remain selectable until the page is refreshed? If it remains selectable, ask what prevents that selection from becoming an accepted order. Then look at a newly opened menu in a separate session. Record both results rather than assuming they match.
Next, attempt the simulated checkout with the existing cart. The useful result is a clear message identifying the unavailable item and a block that prevents the simulated order from being accepted while that item remains in the cart. The guest should be able to remove it or choose something else without guessing what went wrong. Ask whether the rest of the cart stays intact.
If checkout proceeds with the sold-out item, or the message does not make the problem clear, treat that as a buying concern. Ask whether a different setting changes the behavior. If it does not, decide whether the operational fallback is workable: staff may need to pause the channel or monitor incoming orders and contact affected guests. That fallback takes time and does not give guests the same protection as a checkout block.
Separate this simulated check from a live service pilot. A live pilot uses the restaurant's normal ordering process and may involve real guests and fulfillment. Start it only after the safe checks are complete, staff know the fallback, and the manager has decided how to handle a genuine availability problem. Do not use a real guest, payment, or courier as a practice tool.
Compare what each ordering channel shows
Make a list of every place a guest can order the affected item: your direct ordering menu, any ordering link on your restaurant website, and each other channel your restaurant actively uses. A link may lead to the same menu rather than a separate channel; check the guest's path rather than assuming every link has its own settings.
For each separate menu, find out where staff change availability and who owns the update. Ask whether a change made in one place carries over to the others, and demonstrate it for the channels you use. Do not assume an integration shares item availability just because it passes orders.
The table below shows how to record a short simulated check. Its results are hypothetical, not claims about a product. The elapsed times describe when a tester observed a change; they are not guarantees for a later service.
| Guest path | Check | Example observation | Staff action |
|---|---|---|---|
| Direct menu, already open | Select item after update | Still selectable until refreshed | Check cart protection and tell staff not to rely on the open-page display alone |
| Direct menu, newly opened | View item after update | Unavailable when checked one minute later | Record the time and repeat on the devices guests commonly use |
| Separate ordering channel | Open its public menu | Item still available when checked two minutes later | Update that channel separately or use its agreed fallback |
Use a clock or timestamp for each update and each observation. Check a fresh session as well as a page already open. If the item stays available, find out whether a refresh, a separate update, or a support call is needed. Record the actual steps beside the channel name so the backup person can follow them during service.
Do not turn one observation into a promised update time. Repeat the check when the menu setup changes, and ask the vendor what behavior to expect when a device has a weak connection. A practical comparison includes the number of separate updates staff must make, not just how quickly the first screen changes.
Restore the right item at the right time
Getting stock back does not always mean every version of an item should return immediately. A sauce may be available again while one size is still sold out. A lunch special may be ready for tomorrow but should not appear during tonight's dinner window.
Before restoring an item, have the kitchen confirm what can actually be made. The assigned person should check the item, its affected sizes and add-ons, and the intended service window. Ask the vendor whether restoring a parent item also restores its options, and whether availability can be limited by service period. If those controls are not available, agree on a manual step that prevents the wrong option from appearing.
Then check the guest view again. Open a fresh menu, find the item, and inspect the choices that should and should not be available. Repeat for each separately managed channel. In a safe simulation, add an available option to a cart and confirm that an unavailable option cannot be ordered. Do not make a real payment or trigger a guest message or courier dispatch for that check.
Close the loop with the kitchen and front-of-house team: say which item is back, which options remain unavailable, and which channels have been updated. If one channel cannot be restored promptly, leave it on the shift note with an owner and a follow-up time. This keeps a partial restoration from being mistaken for a complete one.
For a wider look at ordering-system decisions, read the online ordering guide. Then review Fleksa's restaurant ordering system and, if it fits your restaurant, ask for a demonstration using your own sold-out item, cart, channel, and restoration checklist.
Frequently asked questions
Is hiding a sold-out item enough?
Not by itself. Check what happens in menus guests already have open and in carts that already contain the item. A clear checkout block is important if the restaurant cannot fulfill it.
Who should update the online menu during service?
Assign a primary person with access and a named backup for each shift. The kitchen should report the exact item and options affected, and the person making the change should confirm when it is complete.
When should an item go back online?
Restore it after the kitchen confirms availability and staff check the correct variants and service window. Verify the guest view on each separately managed channel before telling the team the item is fully back.
