When one option sells out, keep the main item available if a guest can still make every required selection. Mark the unavailable modifier as sold out or remove it from the choices, while leaving the remaining valid options orderable. If no valid required choice remains, stop the order for that item until you can offer a substitute.
The distinction matters during a busy shift. Running out of oat milk should not automatically remove every coffee from the menu. But if a drink requires a milk choice and none is available, the menu should not let a guest submit an incomplete order.
The right setup depends on how your menu groups choices, how prices change, and what happens when availability changes after a guest has started an order. Work through those points with the person who manages your menu and the team responsible for updating stock.
Start with required and optional choices
A modifier is a choice attached to a menu item: a bread type, sauce, protein, milk, or extra topping. A modifier group collects related choices. Some groups require a selection before the guest can proceed; others are optional.
Before changing the display, write down four things for each group:
- Selection rule: Must the guest pick one choice, several choices, or none? Is there a maximum?
- Availability: Which choices can the kitchen actually fulfill, and who updates them?
- Price: Does each choice change the item price, and can a combination change the total?
- Dependency: Does one choice limit another, such as a size that is unavailable with a particular milk?
The kitchen or shift lead can identify what is unavailable and when it is expected back. The menu manager can supply the selection rules and prices. The ordering provider can explain which controls the software supports and where staff make changes. Agree on a backup person for busy periods; an accurate menu is less useful if only one employee knows how to update it.
For a required group, check whether at least one valid choice remains. If the group requires two selections, check that two eligible choices remain and that the guest can select them under the group rules. One remaining choice is not enough merely because the item still appears on screen.
For an optional group, the base item may stay available without an add-on. That does not mean every combination is valid. An optional sauce might depend on a particular protein, for example. Ask the provider whether the menu can enforce that relationship or whether staff must use a simpler setup.
Decide whether to hide or disable an option
An unavailable option can be hidden from the list or shown in a disabled state with a clear sold-out label. Both approaches can work. The better choice depends on what guests need to understand and how reliably the menu updates.
Showing a disabled option tells a regular guest why a familiar choice is missing. It can also make an unexpected substitution easier to understand. The downside is a longer list, especially if several options are unavailable. A disabled choice must look different from an available one and must not be selectable.
Hiding an unavailable option keeps the list short and directs attention to choices the kitchen can make. It can be useful for a seasonal or rarely ordered add-on. The trade-off is that guests may wonder whether the option was removed permanently. If a missing choice changes the nature of the item, a note or a temporary menu adjustment may be more helpful than silently hiding it.
For either presentation, check the item page, any quick-order view, and the cart. A sold-out label on one screen does not help if another screen still allows the choice. Ask whether availability changes apply to all ordering views and whether staff can set an option back to available without rebuilding the item.
Also decide what staff should do when no valid required choice remains. The item needs to be unavailable for ordering or otherwise prevented from reaching checkout until the requirement can be met. Avoid leaving a guest to discover the problem only after filling a cart.
Check prices and dependent selections
Use a small, clearly defined scenario before changing a live menu. The following examples are hypothetical; their prices and behavior are not claims about a particular ordering system.
Suppose a sandwich costs $10, includes one required bread choice, and has an optional avocado add-on for $2. White and wheat bread are valid choices. Wheat sells out, but white remains available. A guest who chooses white and avocado should see a $12 item total: $10 plus $2. Without avocado, the total should be $10.
If white also sells out, the sandwich cannot be ordered under that required-choice rule. If avocado alone sells out, the sandwich can still be ordered with an available bread at $10. This example includes the base item and the selected modifier only. It excludes delivery charges, processing-related charges, applicable tax, other fixed or variable operating costs, and exception costs; it is not an operating-cost estimate.
Now consider a dependency: avocado is offered only with wheat. If wheat becomes unavailable, the menu must not allow white bread with avocado under that rule. Check whether the system removes or disables avocado after white is selected, and whether it recalculates the price if the guest changes bread after adding avocado. If the software cannot enforce the relationship, simplify the menu or use a documented staff process rather than relying on guests to interpret a confusing list.
Ask about defaults, too. A preselected choice that sells out can create an invalid item before the guest touches the screen. The system should require a valid replacement where a selection is mandatory. An optional sold-out add-on should not remain selected or continue to add a charge without the guest noticing.
Test availability changes from item page to cart
Use a test environment or another isolated setup with simulated orders. Do not use a real card payment, send a guest message, or dispatch a courier during practice. Include the menu manager and someone who understands the kitchen's actual selection rules.
The table gives a compact set of cases. In each one, compare what the guest sees with the expected result. A pass requires both a valid order and a clear explanation when the guest must make another choice.
| Case | Change | Expected result |
|---|---|---|
| Required choice | One bread sells out; another remains. | Unavailable bread cannot be selected; the item remains orderable with a valid bread. |
| Required choices exhausted | All eligible breads sell out. | The item cannot reach checkout without a valid required selection. |
| Optional add-on | Avocado sells out. | The guest can order without it, and no avocado charge remains. |
| Existing cart | Selected avocado sells out after the item is added. | The guest is told about the change and can review a valid item and updated total before submitting. |
| Dependent choice | The guest changes bread after selecting an add-on limited to the original bread. | The invalid combination is blocked or corrected with a clear prompt and accurate price. |
| Back in stock | A staff member restores an unavailable choice. | The choice becomes selectable in the relevant ordering views at the correct price. |
For the existing-cart case, ask exactly when the system rechecks availability: when the item is edited, when the cart opens, or when the guest submits the order. Also ask what the guest must do next. Removing an option silently may leave a valid total but still produce an order the guest did not intend. A clear prompt to review the change is preferable.
Try the reverse sequence as well: open the item, select an option, make that option unavailable in the test setup, then attempt to add the item to the cart. Check required groups with minimum selections greater than one, if your menu uses them. Repeat on the devices and ordering views your guests commonly use.
After simulated checks, a live service pilot is a separate operational decision. If you run one, brief the shift lead, choose who will monitor incoming orders, and agree how staff will handle an unavailable choice before service starts. Real orders can involve real guests and fulfillment; do not treat them as practice transactions. Restore normal menu settings afterward and review any problems with the provider.
To evaluate your current setup, give the table to your menu manager and ask your provider to demonstrate the cases that matter for your menu. For broader context, read the online ordering buying guide and consider how ordering appears on your restaurant website. Then ask Fleksa about its restaurant online ordering setup, including current US availability and support for your modifier rules.
Frequently asked questions
Should a whole item be marked sold out when one modifier is unavailable?
Not necessarily. Keep it orderable if guests can still satisfy every required selection and the kitchen can fulfill the remaining combinations. If no valid required selection remains, prevent the item from being ordered until that changes.
Is it better to hide a sold-out modifier or show it as disabled?
Show it disabled when guests benefit from knowing a familiar option is temporarily unavailable. Hide it when a shorter list is more useful. In either case, make sure it cannot be selected and that the same availability applies across ordering views.
What if a modifier sells out after a guest adds it to the cart?
The guest should be alerted and given a chance to review a valid selection and updated total before submitting. Ask your provider when availability is rechecked and how its cart handles that change.
