When a QR order appears under the wrong table, first match the order to the guest using its items and approximate order time. Then confirm where the guest is sitting, tell the kitchen and runner where to deliver it, and check the original code after the immediate service issue is under control. Do not create a second order just to change the table number.
The correction may be a table change in your software, a clearly communicated runner instruction, or both. The right action depends on what your system allows and whether the order is already being prepared. One staff member should own the correction until the food reaches the right guest.
1. Validate the order before changing its destination
Start with the guest who reported the problem. Ask what they ordered, roughly when they placed it, and where they are sitting now. Check those details against the order on the screen. If the guest has an order confirmation, use its order number as another identifier.
Look at the complete order, including drinks, modifiers and special instructions. Two parties can order the same burger within minutes. An item name alone is not enough to justify moving a ticket. If details do not match, pause and investigate rather than assigning the order to the nearest plausible party.
Confirm the guest’s current physical location in plain language: “You’re at table 12, beside the window, correct?” A table number in software and a table in the dining room may not mean the same thing during a mix-up. If tables have been joined, note the specific party or seat area so a runner does not deliver to another group at the same combined table.
Next, check the order’s preparation and payment status. Has it reached the kitchen? Is it being made, ready, or already delivered? Is payment shown as complete, pending or unpaid? Payment status matters to the eventual closeout, but it does not establish where the food should go. Avoid charging again or asking the guest to reorder while the original ticket is still active.
If you cannot confidently match the order, ask a manager to review the available details. Keep the guest informed and give the kitchen a clear hold instruction if preparation or delivery could otherwise put food in the wrong hands. Follow the restaurant’s normal procedures for food safety and payment questions.
2. Find out why the table is wrong
Once you know which guest owns the order, compare three things: the table shown on the ticket, the guest’s present location, and the code they used. The guest may have moved after ordering. A printed sign may have been moved during cleaning or table setup. Or a previous table session may still be associated with the order, depending on how the system handles sessions.
Ask the guest whether they scanned at their current seat or somewhere else. If they can point out the sign, compare its printed table label, if it has one, with its physical location. Do not assume the printed number proves the code’s destination: a sign can have the right label and still open the wrong table.
If the guest moved after placing a valid order, the immediate problem is delivery to the new location. If the sign itself appears misplaced or misdirected, remove it from guest use until it can be checked. If the code appears correct but the order is associated with an earlier session, ask the software provider how sessions are opened, closed and reassigned. Staff should not guess at a session reset while an active order is being prepared.
A guide to where QR ordering fits in table service can help you decide who should monitor these handoffs. For this incident, the immediate priority is one identified order and one confirmed destination, not a full audit of every code in the dining room.
3. Redirect the existing order, not a duplicate
Use the order identifier when speaking to the kitchen and runner. State the old table shown on the ticket, the confirmed destination, and whether the food should continue, be held or be delivered. Ask the recipient to repeat the destination. A verbal message to one person is not enough if another person will actually run the food.
If your software allows an active order’s table to be corrected, follow your established procedure and confirm what the kitchen and runner will see afterward. Does their existing ticket update, print again, or remain unchanged? Until you know, communicate the correction directly rather than assuming every screen has changed. If the table cannot be changed safely, retain the original order and use a clear handoff identifying its destination.
The following decision table shows how to act on the information available. It separates the guest’s location from the cause of the mismatch; either way, the team keeps track of the original order.
| What you find | Immediate action | Before delivery |
|---|---|---|
| Guest moved after ordering | Confirm the new table and update the order if your procedure permits. | Tell the runner the order ID and new destination. |
| Code or sign appears to point to another table | Remove the sign from use and confirm the guest’s current table. | Tell the kitchen and runner where this order belongs. |
| Possible prior session association | Keep the existing ticket identifiable; ask a manager to check the session. | Use a direct handoff until the destination is clear. |
| Order details do not match the guest | Pause the correction and investigate with a manager. | Do not deliver or duplicate the order on an assumption. |
A hypothetical service example
A guest at physical table 12 says their order is showing as table 8. The guest identifies a grilled sandwich, a salad and the approximate order time. Those details match order 314, which the kitchen has started. The guest says they scanned at table 8 and then moved to table 12.
The server confirms table 12 with the guest and checks that order 314 is the only matching active order. The server tells the kitchen to continue and tells the runner: “Order 314 shows table 8; deliver the sandwich and salad to table 12 by the window.” The runner repeats the destination. The server follows the restaurant’s procedure for recording the table change and checks the payment status without charging the guest again.
If the software cannot update the active ticket, the same order still needs a visible or verbal handoff under the restaurant’s procedure. The correction is complete only when the runner confirms delivery to the identified party, not merely when someone changes a field on a screen.
4. Close the correction and check the code
After delivery, confirm that the guest received the full order. Resolve any payment issue separately using the displayed status and your normal payment procedure. Record enough for the next shift to understand what happened: order ID, displayed table, actual destination, whether the guest moved, the apparent code issue, and who handled the correction. Avoid recording unnecessary guest information.
If the guest moved and the sign was correctly placed, return to normal service after closing the handoff. If a sign or session may have caused the mismatch, keep the affected code out of use until someone responsible checks it. A temporary staff-assisted ordering method is better than leaving a suspect sign on the table.
For a safe practice check, use a vendor-provided demo or training environment, if available. Scan the affected code and verify the table identity that appears without submitting a real order. Do not make a real card payment, send a guest message or dispatch a courier during practice. If a full order-flow check is needed, ask the vendor how to simulate it without those real-world actions.
A live service pilot is different: it involves actual guests and active orders. Use it only after the non-transactional check, with an owner assigned to watch the handoff and a fallback ready if the table identity is wrong. It cannot substitute for a safe simulation of payment or messaging.
When evaluating a restaurant POS system or restaurant management software, ask the vendor to demonstrate how an active order is reassigned, what each staff screen displays, and how a previous table session is closed. Also ask what staff should do when a table cannot be changed after preparation starts.
Fleksa’s QR ordering lets guests scan, order and pay at the table in a browser without downloading an app. Compare the workflow above with your requirements and ask for a demonstration of the table-correction and staff-handoff steps before choosing a setup.
Frequently asked questions
Should staff cancel and recreate a wrong-table order?
Not as the first response. Verify the existing order and its preparation and payment status. Recreating it can produce a duplicate ticket or charge. If cancellation is necessary, a manager should follow the restaurant’s established procedure.
What if the guest moved after scanning?
Confirm the guest’s new physical table and match their items and order time to the existing ticket. Tell the kitchen and runner the order ID and new destination, and update the table in the system if your procedure allows it.
How can staff check a suspect QR code safely?
Remove it from guest use and scan it in a demo or training environment, if available, to inspect the table identity without submitting a real order. Ask the provider how to simulate any further steps without a real payment, guest message or courier dispatch.
