When a guest moves with an open QR ordering cart, the safest rule is to confirm the new table before the guest submits. If the system can carry the cart to the new table and clearly show the updated destination, let the guest review and order. If it cannot, reset the cart or ask staff to help. Do not let an uncertain table assignment pass as confirmed.
The distinction matters: this is a cart that has not yet been submitted. Correcting an order already sent to the kitchen is a different service problem, with food preparation and payment status to consider.
Trace the cart from table A to table B
Consider this hypothetical example. A guest scans the code at table A, adds a sandwich and a drink, and then moves to table B at a staff member's request. The guest has not submitted or paid. Both letters identify physical tables, not separate guest parties.
The cart may still be associated with table A even though the guest and phone are now at B. Merely walking to B does not prove that the ordering system knows about the move. Nor does a menu page showing the right items prove that the eventual order will carry the right table.
Start by asking what happens when the guest scans B's code with the cart still open. Does the same cart appear? Does the screen explicitly identify B? Is there a confirmation step? A system might preserve the items, start a fresh cart, or handle the scan another way. Your operating rule must match what the configured system actually does.
Next, follow the intended destination beyond the guest screen. Before allowing submission, the guest should have a clear way to see or confirm B. Once an order is submitted, the order record and the destination used by staff or the kitchen should also identify B. A correct label on one screen alone is not enough if another part of the workflow still points to A.
Think through other ordinary moves as well. A guest may scan a code printed on a nearby table by mistake, move twice, or return to A after scanning B. A staff member may also move a party to join another table. Decide whether guests should scan again for every move and how staff will explain that step without asking guests to guess which table is active.
For a broader view of where the guest scan fits into service, see the guide to choosing where QR ordering fits. The table-move decision is narrower: preserve the order only when the destination can be confirmed.
Choose between rescan, reset and staff help
The worksheet below compares three possible responses to the same move from A to B. It is a decision aid, not a claim that every QR product supports each response. Ask the vendor to demonstrate the option in your intended setup before making it a house rule.
| Option | What happens to the cart | Use it when | Stop or fallback |
|---|---|---|---|
| Rescan B | Keep items only if the system carries them to B and shows B clearly. | The guest can confirm B and the downstream order destination agrees. | If the destination or cart state is unclear, do not submit; ask staff for help or reset. |
| Reset and start at B | Discard the unsubmitted cart and rebuild it after scanning B. | Cart transfer is unavailable or cannot be verified, and the guest is willing to re-enter items. | If a fresh session still cannot identify B, stop and use the staff fallback. |
| Staff-assisted transfer | Staff help establish B; whether items can be retained depends on the system. | There is a defined staff procedure and the resulting destination can be checked. | If staff cannot confirm B, take the order through an approved alternative. |
For this example, rescan is the convenient choice only if it meets the stated checks. Retaining the sandwich and drink is useful, but not at the expense of an unknown destination. If the scan opens a fresh cart at B instead, the guest can rebuild the order. Staff should explain that the first cart was not submitted, so the guest does not assume food is already being prepared.
Staff assistance can be as simple as showing the guest the correct code and checking the displayed table. It might also involve a staff-controlled reassignment, if that function exists in the chosen setup. Ask who is allowed to make that change, what they see afterward, and whether the guest must confirm again. Do not build your procedure around a transfer button until you have seen it work.
Keep a non-phone fallback available. Depending on your service model, staff might take the order directly or direct the guest to a counter. Write down how that order is associated with B and how payment is handled. The fallback should not depend on the guest solving a confusing cart problem while service continues around them.
Check the displayed table and order destination
Use a controlled simulation to evaluate the move before relying on it during service. Set up two clearly labeled physical test tables, A and B, with a cart containing a couple of recognizable items. Ask the vendor how to run the complete check without creating a real payment, sending a guest message, dispatching a courier or producing a live kitchen ticket. If the system cannot safely simulate a step, inspect the available settings and ask for a demonstration rather than triggering a real transaction.
- Start at A. Scan A and add the items. Record what identifies the table on the guest screen and whether the cart is still unsubmitted.
- Move to B. Scan B with the cart open. Note whether the items remain, disappear or require another action. Look for an explicit table label or confirmation, not just the presence of a menu.
- Review before submission. Check that the guest can see the intended destination and items together. If B is not identifiable, the attempt has not passed.
- Inspect the simulated result. Where a safe simulation is available, check the order record and the staff or kitchen view used for fulfillment. Each must identify B consistently. Confirm that the simulated payment state is not mistaken for a real payment.
- Repeat the exception. Try a move back to A and a fresh session at B. Check what happens if the guest closes and reopens the page. Record the observed result for each path.
The acceptance boundary is straightforward: a retained cart passes only when the guest-facing destination is B before submission and the simulated order and fulfillment views also identify B. A reset path passes only when the old cart is not submitted and a new order can be clearly associated with B. If the relevant destination cannot be inspected or the labels disagree, treat the path as unverified, not as a pass.
Run the check with the actual service arrangement in mind. If food runners rely on a printed ticket, inspect the simulated ticket or a safe preview. If staff use a kitchen display or POS screen, inspect that view. Ask whether table names are shared across those views and what happens when a table label is changed in the restaurant setup.
Fleksa's QR ordering software lets guests scan, order and pay at the table in a browser without downloading an app. Ask how the cart, table identity and staff handoff work for a move in your configuration. If you use other restaurant management tools, include the views your team will actually use in the check.
Set a safe stop and train the handoff
Give staff a short rule they can use during a busy shift: if the current table cannot be confirmed, do not submit the cart. Ask the guest to pause, then either establish B through a verified rescan, start a fresh cart at B, or use the staff ordering fallback. The aim is a known destination before an order enters the fulfillment workflow.
Make the guest-facing instruction specific. For example: “You've moved to table B. Please scan this code and check that B appears before ordering. If it doesn't, I'll help.” Avoid saying that the cart has moved until someone has confirmed it. If a reset is needed, explain that the guest must add the items again and review them before submission.
Practice the conversation and simulated checks outside live service. Staff should know where to find the table label, when to stop and whom to ask if the system behaves differently from the documented procedure. A simulation must not initiate a real payment, message or dispatch. A live service pilot is separate: use the established ordering process with staff monitoring real orders, payments and fulfillment, and stop using the new procedure if the destination cannot be verified.
Keep the written procedure short enough to use at the table, but include the fallback. After a menu, table layout or system change, repeat the relevant checks before relying on the old instructions. Ask the vendor how to report a mismatch and what information staff should capture without exposing unnecessary guest details.
Next step: Take the A-to-B worksheet to your vendor demonstration and ask to see the guest, order and fulfillment views for your setup. You can discuss your requirements with Fleksa and compare the workflow with its current product fit.
Frequently asked questions
Should a guest rescan after moving tables?
Rescanning is a practical option if it establishes the new table and the guest can confirm it before submitting. Check that the order and fulfillment views use the same destination. Otherwise, reset the cart or use staff assistance.
Should the guest keep an open cart after moving?
Keep it only if the system can carry it to the new table with a clearly verified destination. If that cannot be confirmed, discard the unsubmitted cart and rebuild it at the new table, or use an approved staff fallback.
What if the guest has already submitted the order?
Use your procedure for an existing order rather than the open-cart rule. Staff need to check where the order was sent, whether preparation has begun and what the payment status is before deciding how to correct the destination.
