When an item sells out while it is sitting in an open table cart, checkout should stop that item from being submitted as available. The guest should see which item changed, choose how to proceed, and approve the final order and price before submission. The kitchen should receive only the items in that approved order.
That sounds simple, but the details matter: a substitute may have a different price, a modifier may not transfer, and a payment attempt may already be underway. Agree on the expected behavior before buying or configuring a system, then walk through it with the vendor.
Start with an open table cart
Use a small, hypothetical order to make the decision concrete. A guest at table 6 has a cart containing a $14 mushroom burger with a selected no-onion modifier and an $8 salad. The displayed food subtotal is $22. Before the guest submits the order, the restaurant marks the burger unavailable.
For this example, assume availability can be updated during service and the system checks it again before accepting the order. Ask the vendor to demonstrate both steps. The $22 is a food subtotal only: it excludes applicable tax, tips, payment processing fees and any other charges. It is not an all-in operating cost or a claim about a particular product.
The important boundary is between an editable cart and an accepted order. A guest adding the burger to a cart does not, by itself, mean the kitchen has accepted it or that the last burger is reserved. Ask whether the system reserves stock at any point, how long a reservation lasts, and what staff must do when the remaining quantity changes.
Also ask what happens if two guests reach submission at nearly the same time and only one serving remains. The behavior should be clear to the losing guest and staff, without leaving an order that looks accepted on one screen and rejected on another.
Choose how the guest resolves the conflict
There are three useful paths to compare. The right choice depends on your service style and what the software can actually demonstrate.
| Path | Guest decision | Acceptance check |
|---|---|---|
| Remove and continue | Remove the unavailable burger and keep the salad. | The revised cart shows the $8 food subtotal and submits only the salad after approval. |
| Choose a substitute | Select an available $16 chicken sandwich and review its options. | The cart shows the new item and $24 food subtotal; no modifier transfers without being shown and confirmed. |
| Ask staff | Pause checkout and request help using the restaurant's available service channel. | Staff can identify table 6 and the unresolved item; no unapproved replacement reaches the kitchen. |
The table sets a decision boundary: the unavailable burger must not go through as if it were still available. The guest may continue with the salad, explicitly approve a substitute, or stop and get help. For the substitute path, assume the chicken sandwich is available and that no modifier has been selected for it yet. The $24 subtotal is $16 plus $8, with the same exclusions as the original example.
Removal is often the cleanest default because it does not invent a preference. Substitution is useful when the guest can actively choose another item and review its price and options. Staff assistance fits restaurants where a server can explain alternatives, but the restaurant needs a dependable way to connect that request to the right physical table.
Do not make a replacement automatic just because two dishes seem similar. A guest who chose no onion on a burger may need to make a different selection on a sandwich. If a substitute cannot be reviewed and approved in the cart, use removal or staff assistance instead.
For a broader service-model decision, see the guide to where QR ordering fits in table service. The cart conflict still needs its own check even if the rest of the QR flow looks straightforward.
Check price, modifiers and submission together
Ask for a simulated walk-through using a test environment or another isolated setup. Confirm with the vendor that the exercise cannot create a real payment, send a real guest message, or dispatch a courier. Use test records that staff can identify and remove without affecting service.
- Build the cart. Add the burger, its no-onion modifier and the salad. Record the displayed items and subtotal.
- Change availability. Mark the burger unavailable after it has entered the cart. Return to the open cart and attempt to continue.
- Resolve the conflict. Try removal first. In a separate run, choose a substitute if that workflow is offered. Review the item name, options and revised subtotal before approving it.
- Inspect the result. Compare the guest's final confirmation with the simulated order record and kitchen view. The approved items, quantities and modifiers should match.
- Repeat around payment. Ask what happens if availability changes just before or during payment, including whether a payment can be authorized without an accepted order and how staff would identify and resolve that state.
For each run, write down the expected result before clicking. If the burger is removed, an $8 salad should remain; the kitchen view should not include the burger or its modifier. If the guest approves the $16 sandwich instead, the food subtotal should be $24 and the kitchen view should reflect the sandwich options the guest actually selected.
Review the full amount presented at checkout separately from the food subtotal. Applicable tax, tips and other charges can change the amount the guest owes. Payment processing fees are a restaurant cost, not a guest sale or a deposit. Ask how each amount appears in the payment and order records, rather than assuming that a revised cart also means every payment state has been resolved.
Fleksa's QR ordering lets guests scan, order and pay at the table in a browser without an app download. There is no Fleksa commission on table QR orders; processing and applicable tax still apply. Ask to see the specific sold-out cart and payment behavior in the setup you are considering.
Make the handoff clear to guests and the kitchen
A useful guest message names the unavailable item and tells the guest what to do next. For example: “The mushroom burger is no longer available. Remove it, choose another item, or ask your server for help.” The actual options shown should match the actions the system and restaurant can support.
The message should appear before the guest believes the order is complete. Check what happens when the guest returns to the cart, refreshes the page, or tries to submit again. Ask whether the cart preserves the remaining salad and whether the guest can clearly see that nothing has been accepted until the conflict is resolved.
For the kitchen, reconciliation means comparing the final approved order with what staff receive. Check the table identifier, item names, quantities, modifiers and order status. A removed burger should not linger as a kitchen instruction; a substitute should not appear with an old modifier that the guest never approved for it.
Include a staff recovery path for uncertain cases. Who checks an order that has a payment record but no accepted kitchen order? Who speaks to the table if the guest cannot complete checkout? Agree on where staff look for the answer and who owns the follow-up. This is part of restaurant management, not just a menu-display question.
After the simulation, consider a limited live-service pilot only when the restaurant and vendor have agreed on safeguards, staff roles and a way to handle real guest orders and payments. A live pilot is not the same as the isolated practice run. Have a non-phone fallback, such as ordering with a server, and stop the pilot if staff cannot reconcile an order confidently.
Before committing, bring this worksheet to a vendor conversation and ask for a demonstration of your chosen resolution path, payment states and kitchen handoff. Discuss your requirements with Fleksa and compare the demonstrated workflow with your service model.
Frequently asked questions
Should a sold-out item be removed automatically from a cart?
The guest should be clearly told what changed and see the revised order before approving it. Ask whether the system removes the item automatically or requires the guest to remove it, and check that the final kitchen order matches the approved cart.
Can a restaurant substitute an unavailable item without asking?
A safer acceptance rule is to require the guest to choose and approve the replacement, its price and its options. If that cannot happen in the cart, have staff help or let the guest continue without the item.
What if payment starts before the availability conflict is resolved?
Ask the vendor to demonstrate the possible payment and order states in an isolated simulation. Staff should know how to identify a payment that does not correspond to an accepted order and how to resolve it with the guest.
