Publish an urgent availability change as soon as you can prevent more guests from adding an item the kitchen cannot make. For a routine price change, wait for a quieter period unless you have confirmed how the system handles carts that already contain the item. In both cases, the decision depends on what happens at submission—not just what the menu shows after publication.
A guest may have scanned a QR code, added an item and then paused to talk. That cart can remain open while a manager changes the menu. Before service, find out whether the guest sees the change, whether the order can still be submitted, and who resolves a mismatch.
Map the four states before changing the menu
Think of the menu change as moving through four separate states. The names and controls in your software may differ, so ask your provider to show you each step.
- Draft: A manager prepares a change. Ask whether saving a draft affects the guest-facing menu or existing carts.
- Published menu: The change is available to guests viewing the menu. Ask whether it appears immediately and whether an already open page must be refreshed.
- Open cart: A guest has selected items but has not submitted the order. Ask whether the cart retains its original item details, updates them, or requires the guest to make another choice.
- Submitted order: The guest has sent the order. Check what price, item details and payment status appear on the ticket, and how staff can act on an exception.
These states matter because seeing a new menu does not necessarily mean an old cart has changed. Likewise, a successful submission does not by itself tell a server whether the kitchen received an item that is still available.
First identify what your QR code actually opens. A digital menu may only display items; an ordering system may also let guests build a cart and submit it. Fleksa’s QR ordering lets guests scan, order and pay at the table in a browser without downloading an app. For any system, ask how the cart, ticket and payment steps are configured for your service model.
Assign a person to make urgent changes and another person to relay exceptions if the manager is occupied. Decide how the kitchen will report a sellout, how the floor will be notified and who can make a correction. A menu control is useful only if the people working the shift know when to use it.
Use a decision worksheet for open carts
The following is a hypothetical example, not a description of Fleksa’s cart behavior. Assume a restaurant has eight physical tables. Three guest parties have open carts, and one of those carts contains the last portion of a special. The kitchen has just reported that no portions remain.
Also assume the operator has confirmed that publishing makes the item unavailable on newly opened menus, but has not yet confirmed what an existing cart does at submission. The operator cannot tell which party has the item. The worksheet compares choices against those assumptions.
| Choice | Benefit | Open-cart risk | Shift action |
|---|---|---|---|
| Publish now | New menu visitors should no longer be able to select the special under the stated assumption. | The existing cart may still contain it; its submission behavior is unknown. | Tell the floor and kitchen immediately; watch incoming tickets and resolve any affected order. |
| Wait for quieter service | Staff have more time to coordinate the change. | More guests may select an item the kitchen cannot make. | Manually warn guests until publication; use only if that coverage is workable. |
| Pause QR ordering, if the system offers it | May prevent further QR submissions while staff intervene. | All QR guests may need another ordering route; an open cart may still need attention. | Confirm what the pause actually stops and direct guests to a server. |
Under these assumptions, publish now. Waiting leaves an unavailable special visible to additional guests, while the kitchen has no portions to serve. Publication alone is not the full response: the team still needs to watch for the existing cart and offer a replacement or remove the item if it reaches the ticket.
If the same change were a nonurgent price increase instead, the balance could shift. Waiting until a quieter period gives the operator time to understand and communicate the price shown to guests with open carts. Do not assume waiting clears every cart; ask whether carts expire, how that works and whether staff can see affected orders.
For a wider discussion of how QR service fits alongside servers, use the table-service buying guide. The important choice here is narrower: publish now or wait, based on the consequence of letting another order through and the team’s ability to handle an exception.
Trace a price or availability change to the ticket
Walk through the path from selection to fulfillment before deciding on a policy. For an availability change, start with a guest who adds an item while it is available. The kitchen then sells out, and a manager publishes the change. Ask what the guest sees without refreshing, what happens when the guest submits, and whether the kitchen receives a ticket containing that item.
For a price change, start with an item added at the displayed price. After publication, does the cart keep that price, show a revised price, or ask the guest to review the order? If the price changes, ask when the guest sees the new total and what action confirms it. Then check that the submitted ticket and payment record show the outcome staff expect.
Modifiers deserve the same attention as the main item. A guest may have chosen a size, preparation or add-on before the menu changed. Ask whether a change to one option affects the whole item, whether the guest can choose another option, and how that choice appears on the kitchen ticket. Also ask what happens if the item is removed and later made available again while the cart remains open.
A useful price-check calculation is separate from the sellout example. Suppose a guest adds two drinks displayed at $4 each, and the price later changes to $5 each. The item subtotal is $8 at the original price or $10 at the revised price, a $2 difference. These are item subtotals only: fixed costs, other variable costs and exception costs are excluded. They are not payment-processing fees or an estimate of operating cost. Ask the vendor which subtotal the guest would see at each step and what would be submitted; do not choose a policy based on the arithmetic alone.
If a guest has already submitted, treat that as a separate workflow from an open cart. Ask whether staff can amend or cancel the item, how the kitchen learns of the change, and how any payment adjustment is recorded. A server should not have to infer payment status from the presence of a kitchen ticket.
Choose a resolution path staff can operate
Guest refresh and review
A refresh can be a clear route when it brings the guest to the current menu and gives them a chance to review the cart. Ask whether refreshing preserves unaffected selections, removes unavailable items, or changes prices. A refresh that silently removes a selection may leave a guest thinking they ordered something that never reached the kitchen.
Use this approach only after the vendor demonstrates the guest-facing message and the resulting ticket. Staff should know what to say if a guest cannot see the change or prefers not to rebuild a cart.
Submission rejection
A system may stop an order containing an unavailable item or an outdated price. Ask whether the message identifies the problem, whether the rest of the cart stays intact, and whether the guest can correct it without starting over. Also ask whether staff receive any indication that the guest is stuck.
Rejection can protect the kitchen from an impossible ticket, but it can also leave a table waiting if the message is unclear. During a busy shift, decide who checks on guests who appear to need help. Do not rely on staff seeing an alert unless the demonstration shows that alert in the tools they actually use.
Staff-assisted correction
A server can explain a sellout, offer another item and confirm the guest’s choice. This is also the fallback for guests who cannot or do not want to order on a phone. Give staff a clear route to the right table and a way to check whether anything has already been submitted or paid.
Ask how a correction moves between the guest, staff and kitchen. If a replacement is entered separately, can the team distinguish it from a duplicate? If an item is removed after submission, what appears on the kitchen display or printed ticket? The answer determines whether the fix is practical when the floor is busy.
Demonstrate the workflow and audit the result
Before relying on a policy, ask the vendor to demonstrate it in a safe practice environment. A simulation should not create a real card payment, guest message or courier dispatch. Use test data and a nonproduction route to any kitchen display or printer. Confirm with the vendor how those safeguards work before starting.
- Open a guest cart with an item and a modifier. Record the displayed item price and table identifier.
- Leave that cart open. In the manager view, change the item’s availability or price and publish the change.
- Return to the cart without refreshing. Observe the message, displayed total and available next action. Then refresh and compare.
- Use the simulated submission path. Check whether the item reaches a test ticket and whether the item, modifier, price and table identifier match the guest’s confirmed choice.
- Repeat with a staff-assisted correction. Check the simulated payment status and any cancellation or replacement record, without charging a card.
Ask the vendor to repeat the steps for both a sold-out item and a price change. Also ask what happens if the guest’s connection drops between review and submission. Record the observed behavior and agree on a staff response for each outcome. If the workflow depends on a particular setting, note who can change it and whether it applies to every table.
A live service pilot is different from that simulation: real guests, orders and payments may be involved. If you choose one, brief the team beforehand, keep a non-phone ordering option available, and review actual tickets and payment records afterward. Do not introduce a deliberate sellout or price discrepancy merely to test guests. A pilot can reveal operational issues, but it does not guarantee that every possible cart state has been covered.
Review the full operating quote as well as the workflow. Setup, equipment, payment processing and support can affect the decision; a quoted processing fee alone is not the all-in cost. For current Fleksa plan details, consult Fleksa plans, checked November 2026, and confirm the configuration and charges in a written quote. The QR ordering cost guide can help frame the questions.
Next step: Write down your preferred response for a sold-out item and a routine price change, then compare your requirements with Fleksa and ask for a demonstration of both workflows, from open cart through ticket.
Frequently asked questions
Should I wait for every open cart to close before publishing?
Not necessarily. For an unavailable item, waiting may let more guests select something the kitchen cannot make. Publish promptly when that prevents further selections, and have staff handle any existing-cart exception. For a routine price change, a quieter period may be easier.
Does refreshing a QR menu update an existing cart?
That depends on the system and its configuration. Ask the vendor to show what happens to items, modifiers and prices before and after refresh, including the message the guest receives.
What should staff check after a menu change?
Check that the guest’s confirmed selection matches the submitted ticket, that the kitchen has the correct table and item details, and that payment status is clear. Investigate any cancellation or replacement before assuming the order is complete.
