Staff can safely hand a table to the next party only if the ordering workflow prevents the previous party’s phone session from placing an order against the new party’s visit. Ask the vendor how the old session ends, then verify the behavior in a simulation before relying on it during service.
Closing a check, clearing a table and ending a browser session may be separate actions. Your decision depends on what staff must do, what the old guest can still see or submit, and what happens if an invalid order reaches the restaurant. This is a test of one physical table changing parties, not a guest moving to another table.
Map the handoff from one party to the next
Start by writing down the exact service sequence. A restaurant might settle a check at the POS, clear plates, mark the table available and seat another party. Find out which action, if any, ends the earlier QR session. Do not assume that payment alone does it.
For the following hypothetical simulation, use one physical table, Table 6, and two parties seated there one after the other. Party A has opened the table’s QR ordering page on a phone. Its check is marked settled in a test environment. Staff then complete the vendor’s stated table-closing procedure and seat Party B at Table 6. Party B opens a fresh QR session.
The expected result is straightforward: Party B can start its own order, while Party A’s old page cannot submit an order to Party B’s visit. Party A also should not see Party B’s order or payment details. The exact screen shown to Party A can vary; the important point is that an old page does not retain authority over the new visit.
Before the simulation, ask the vendor these questions:
- What identifies a visit: the physical table, a session, a check, or a combination?
- Which staff action ends the previous phone session, and how can staff confirm it ended?
- Does the same printed QR code serve each new party? If so, how are successive visits kept separate?
- What happens if staff clear the table before the check is settled, or settle it without clearing the table?
- Can the system prevent reseating in QR mode until the required closeout step is complete?
Record the answers as steps a server can actually follow. If the handoff depends on someone remembering a separate action, put that action on the closeout checklist. A workflow that is technically possible but hard to complete during a rush still deserves scrutiny.
Try the old browser against the new visit
Run this as a simulation in a vendor-provided test environment, not during live service. Configure it so no real card payment, guest message, kitchen ticket or courier dispatch can occur. Use staff devices and fictional parties. If the vendor cannot provide a safe environment, ask for a controlled demonstration and do not submit test orders into a live workflow.
On the first device, open Table 6 as Party A. Keep the page open after the simulated check is settled. Have a staff member perform the normal closeout. On a second device, start Party B’s visit at the same physical table. Then return to the first device and try to add an item and submit an order.
Check more than one route back to the old page. Try the page left open, a refresh, and the browser’s back button. If the page has a saved link, reopen that link too. Observe whether the old page is rejected, requires a new session, or allows an order to proceed. A warning that appears after an order has already reached production is not the same as preventing submission.
Also check Party B’s fresh session. It should show the intended table and a clean visit, without Party A’s items or payment information. Ask what happens if Party A scans the physical code again: can the system distinguish a new scan from the old session, and what would stop a departed guest from joining the current visit? A failed old link alone may not answer that question.
If your dining room supports a different sequence, repeat the simulation for that sequence. For example, staff may close a check at the counter while another employee clears the table. The result should not depend on both employees making assumptions about what the other has done.
See what staff can catch and stop
Prevention is the preferred result, but staff also need a clear response when something looks wrong. Ask the vendor to demonstrate the path from a submitted order to the staff screen or POS, including any point at which an order can be reviewed, rejected or stopped. Do not assume every setup has a review step.
In the hypothetical Table 6 simulation, give Party A’s attempted item a recognizable fictional name. If the system lets the attempt through, note where it appears, which visit or check it is attached to, and whether staff can stop it before preparation. Check whether the display shows enough context to distinguish an old visit from the current one. A table number by itself identifies the physical table, not necessarily the party.
Ask who is responsible for resolving an uncertain order. A server might notice an unfamiliar item; a manager might need to cancel it or correct the check. Agree on the steps before service, including how to tell the current party that staff are checking an unexpected item. Avoid showing one party another party’s details while investigating.
Review the connected workflow as well. If orders appear in a restaurant POS system or another staff-facing screen, confirm the handoff for your particular setup. Ask whether an order can be stopped before it reaches preparation, and what staff should do if it has already appeared there. If an invalid order can reach a production screen, the procedure must include alerting the kitchen and checking the current party’s bill.
Keep the test separate from a live service pilot. A live pilot, if you choose one after the simulation passes, uses the agreed workflow with actual diners and normal service controls. Do not use real guests, payments or kitchen dispatches to stage an invalid-order attempt.
Use a pass-or-fail worksheet and set a fallback
The worksheet below gives Table 6 a concrete acceptance standard. Record the observed result beside each item in your own copy. The rows cover both prevention and recovery: a clean new visit is not enough if an old session can still send an order.
| Check | Pass | Fail | Staff response to failure |
|---|---|---|---|
| Close Party A | Staff complete the stated closeout and can confirm the visit is closed. | The required action or its completion is unclear. | Do not seat Party B with QR ordering until the closeout is resolved. |
| Open Party B | The fresh session identifies Table 6 and starts a separate visit without Party A’s order or payment details. | Party A’s information appears or the visit cannot be distinguished. | Stop QR ordering at the table and use staff ordering. |
| Return on Party A’s device | Old pages and links cannot submit an order to Party B’s visit or expose its details. | An old session submits an item or displays Party B’s information. | Stop QR ordering at the table; investigate affected orders and checks. |
| Handle an invalid attempt | Staff can identify the problem and follow a demonstrated stop or correction procedure. | Staff cannot tell which visit received the order or cannot stop or correct it. | Notify the manager and preparation staff; reconcile the current check manually. |
Set the fallback before buying or enabling the workflow. Staff ordering through the normal service process is a practical alternative while the vendor investigates. Tell servers not to invite a new party to use table QR ordering at an affected table until the problem is resolved and the simulation passes again. If staff cannot isolate the problem to one table, pause the affected QR workflow more broadly.
Make the decision from the whole result. If the old session is blocked but staff cannot reliably confirm closeout, the handoff is not ready for a busy dining room. If a submitted invalid order cannot be stopped before preparation, weigh that operational risk against the available safeguards. Ask the vendor to document any required settings, staff actions and limits in the proposed setup.
For the wider service decision, the guide to where QR ordering fits in table service can help you decide when staff should take the lead. A restaurant management software review can also help you map who owns the handoff between the floor and the order screen.
Next, take the worksheet to your vendor demonstration. Compare your requirements with Fleksa QR ordering and confirm current availability and the session-close workflow before choosing how to serve the next party.
Frequently asked questions
Does settling a check close the guest’s QR session?
Do not assume it does. Ask which action ends the session, how staff confirm it, and what an old browser can do after the table is reseated.
Is a printed QR code unique to each party?
That depends on the setup. Ask how a reused table code separates visits and what happens when someone opens an old link or scans the code again.
What should staff do if an old order reaches the new party’s table?
Pause the affected QR workflow, alert the manager and preparation staff, and check the current bill. Use staff ordering until the cause is resolved and the handoff passes a safe simulation.
