When a required side sells out, a QR ordering system should prevent guests from submitting that choice while keeping the rest of the meal available when possible. It should also catch an invalid choice already in a cart and give the guest a clear way to choose again. The kitchen should receive only the final, valid selection.
That sounds straightforward, but the details matter. A system may hide a side, show it as unavailable, or require staff to remove it manually. Ask what happens at selection, cart review, submission, and the kitchen ticket—not just whether a modifier can be marked sold out.
Decide who controls the unavailable choice
A modifier is a choice attached to an item: a side, sauce, cooking temperature, or substitute. Selling out of one modifier is different from selling out of the whole item. If a chicken meal is still available but a side is not, taking the entire meal off the menu may turn away orders unnecessarily.
Give one role responsibility for changing availability during service. Depending on your setup, that could be the shift manager or an authorized kitchen lead. The person needs a quick way to make the change and a backup process if they cannot reach the ordering system. Staff also need to know when the side is available again.
Before comparing software, write down the rules for the modifier group. How many choices must the guest make? Can they choose the same side twice? Are any substitutions priced differently? If too few valid choices remain, can the meal still be prepared as described? The answers determine whether hiding one option is enough or whether staff must change the menu.
Also decide where the guest should see the change. A menu that shows the current choices is useful, but a guest may have started an order before the kitchen ran out. Ask the vendor when availability is checked again and what happens if the guest already has the unavailable choice in the cart.
Compare the ways a system can respond
Hide the unavailable side. This keeps the selection screen short and directs guests toward choices they can order. It works best when enough alternatives remain and the required selection rules still make sense. Ask whether a side already selected in an open cart is also caught; hiding it from new selections alone does not solve that problem.
Show the side as unavailable. A visible label can explain why a familiar option cannot be selected. Check that the label is understandable on a phone and that the choice cannot still be submitted. A long list of unavailable options may make the menu harder to use, so consider how often your selections change.
Replace or edit the choices manually. A manager might remove a side or add an approved substitute. This gives the restaurant control over what the kitchen can actually prepare. It also creates work during a busy shift. Confirm whether the change affects only new carts or also prompts guests with existing carts to review their choices.
Pause the meal. If the kitchen cannot meet the meal's required choices, stopping orders for the whole item may be safer than accepting incomplete meals. This is a useful fallback, but it is too broad when valid sides remain. Ask how staff can pause and restore the item, and how guests with it already in their carts are notified.
Do not assume that the system can automatically pick a replacement. A substitute may have a different price or may not be acceptable to the guest. If a vendor offers automatic substitution, ask how consent, price changes, and the kitchen ticket work.
Use a two-side worksheet
The following example is hypothetical. A meal requires two different sides. The available choices are rice, salad, and fries. A guest selects rice and fries. Before the guest submits the cart, the shift manager marks fries unavailable. Rice and salad remain available, so the meal can still be ordered with two different sides.
Use the table to agree on the result you need and who acts next. The ticket row assumes the guest changes fries to salad and submits the corrected order. It does not assume a particular vendor supports these behaviors.
| Stage | Expected result | Next action |
|---|---|---|
| New selection | Fries cannot be selected after the status change; rice and salad remain selectable. | Guest selects two different available sides. |
| Existing cart | The cart identifies fries as unavailable and prevents submission with that choice. | Guest replaces fries with salad and reviews the meal. |
| Order submission | The corrected order contains rice and salad, with no unavailable side. | Guest submits; staff monitor the order through their normal workflow. |
| Kitchen ticket | The ticket shows the meal with rice and salad, not fries or an unexplained blank. | Kitchen checks the ticket and prepares those sides. |
| Too few sides remain | The guest cannot submit a meal that fails the two-different-sides rule. | Manager restores a valid choice, changes the meal setup, or pauses the item. |
Pay particular attention to the existing-cart row. The guest made a valid choice at the time, so a generic error may not be enough. Look for a message that identifies the affected meal and choice, explains what to do, and preserves the rest of the order where possible. Ask whether the guest must reopen the item, whether the updated price is shown if a replacement costs more, and whether the cart retains table identity.
Now consider a separate timing issue: what if the order was already accepted before the manager changed the status? Ask the vendor where staff can see that order and how they should resolve it. The team may need to contact the table and agree on a replacement. Do not expect a later menu change to rewrite an accepted kitchen ticket unless the vendor demonstrates that workflow and explains its consequences.
If a guest cannot use a phone or cannot complete the correction, staff need another path. Decide whether an employee will take the corrected order at the table or use the POS. Check how that order is associated with the physical table and how staff avoid entering it twice. Your restaurant POS system and kitchen workflow should be part of the discussion, not an afterthought.
Run a vendor acceptance test before buying
Give each vendor the same written rules and expected results. Ask for a demonstration in a safe test environment with simulated orders. The practice must not charge a card, send a real guest message, or dispatch a courier. Confirm how the vendor isolates the test before starting.
- Set up the meal. Configure two required, different sides with three choices. Pass if the guest cannot proceed with fewer than two choices or select the same side twice under these rules.
- Change availability. Put rice and fries in a test cart, then mark fries unavailable. Pass if a new guest cannot select fries and the existing cart identifies the conflict before submission.
- Correct the cart. Replace fries with salad. Pass if the guest can review a valid meal and the order retains the correct table information.
- Inspect the ticket. Submit the simulated corrected order. Pass if the kitchen view or test ticket shows rice and salad clearly, without fries or a missing required side.
- Try the exception. Leave only one valid side available. Pass if the system prevents an order that breaks the two-side rule. Check what staff must do to restore a workable menu.
- Practice recovery. Ask an employee to handle a guest who needs help changing the choice. Pass if the employee can explain the next step, identify the table, and avoid a duplicate order using the agreed workflow.
Record a fail when a result depends on a step your team cannot reliably perform during service. A system may allow a manager to edit a menu but still leave an old cart unchecked. Ask the vendor to show the complete path rather than accepting a feature name as proof.
For support, ask: who can change modifier availability, how quickly should the change appear, and whom do we contact if carts or tickets show conflicting choices? Also ask whether the behavior depends on your POS, kitchen display, or configuration. Include setup and staff training in the written quote, along with recurring charges and any exception-handling work your team expects to do.
Once the simulated checks pass, decide whether a limited live service pilot is appropriate. Train the shift team first, tell them who owns availability changes, and monitor actual orders through normal service procedures. A live pilot involves real guests and orders; it is not the same as a simulated practice.
For the wider service decision, use the guide to where QR ordering fits in table service and consider how changes reach your restaurant management software. Fleksa's QR ordering lets guests scan, order, and pay at the table in a browser without downloading an app. Compare your modifier requirements with Fleksa and ask for a demonstration of the exact availability and ticket behavior you need.
Frequently asked questions
Should an unavailable side be hidden or shown as sold out?
Either can work if guests cannot select it and existing carts are checked. Choose the display your guests can understand, then verify the behavior after availability changes.
Should the whole meal be marked unavailable when one side sells out?
Not necessarily. Keep it available if enough valid choices remain and the kitchen can fulfill the meal. Pause it if the required choices can no longer be met.
What should happen if a side sells out after an order is accepted?
Staff need a clear way to find the order, contact the table, and agree on a replacement. Ask how the correction reaches the kitchen and how any price difference is handled.
