When a guest closes the browser before submitting a QR order, the cart may return when they reopen the link, or they may have to start again. The answer depends on the ordering system, its session settings, and how the guest returns. Ask the vendor to demonstrate the behavior you expect before you buy.
The operational question is bigger than whether the food is still visible on a screen. A guest needs to know whether the cart is a draft or an order the kitchen has received. Staff need a clear next step if the cart cannot be recovered.
Decide what recovery should do in your dining room
The owner or manager choosing the system should set the acceptance rule with the person responsible for the dining room. Include whoever handles POS setup and staff training. They will need to understand what a guest sees and what staff can actually find.
Start with the normal service path. Does one guest scan the code and order for the party, or do several people order separately? Is the code tied to a physical table? When guests submit, does staff review the order or does it go straight to the kitchen? Those answers shape what a useful recovery flow looks like.
A cart is not a submitted order just because it contains items. A useful draft screen should say that the guest still needs to submit. A submitted-order screen should clearly show the order status and the next step, including payment status where relevant. Ask the vendor what information staff can see at each stage.
Table identity matters too. If a guest returns to an old cart after changing tables, the restaurant should not assume the old table is still right. Decide whether the guest must confirm the table again, whether staff can correct it, and what happens if the original table is no longer available.
Fleksa's QR ordering lets guests scan, order, and pay at the table in a browser without downloading an app. Ask how its cart recovery and expiry settings work for your setup; do not assume that a browser-based flow preserves an unfinished cart.
Compare restoring the cart with starting fresh
Restoring an unsubmitted cart can spare a guest from choosing every item again. It is worth considering when orders commonly contain several customizations or when guests may put down their phones while deciding. The restored screen must still make the draft status obvious and allow the guest to review the contents before submission.
Restoration also creates questions. A menu item may no longer be available, its price may have changed, or the guest may have moved. Ask whether the system checks those details when the cart returns, and what the guest sees if something needs attention. A restored cart should not silently become a submitted order.
Starting a new cart gives the guest a fresh view of the menu and can avoid carrying an old table or stale selection forward. It may be reasonable for a short menu or a service model where staff are nearby to help. The tradeoff is that guests must rebuild their choices, including modifiers, and may not understand why their earlier work disappeared.
A fresh start is a poor fit if rebuilding a complex party order routinely delays service and the vendor provides no helpful fallback. Restoration is a poor fit if the system cannot clearly handle expired sessions, changed items, or table confirmation. Neither approach solves uncertainty unless the guest can tell whether an order was actually submitted.
Also ask which return paths count. Reopening the same browser, scanning the same code again, opening a different browser, and switching phones may produce different results. Private browsing or cleared browser data may matter too. Have the vendor explain the limits in plain language rather than assuming every return path behaves alike.
Use a worksheet for an interrupted session
The following is a hypothetical acceptance scenario, not a claim about any product. A restaurant has eight physical tables. One guest at table 3 builds an unsubmitted cart for a party of three, then closes the browser. The manager wants a cart reopened within 15 minutes to return as a clearly labeled draft. After 30 minutes, the restaurant's chosen rule is to start fresh. The vendor must confirm whether it can support those rules and how the interval is measured.
The table records the restaurant's desired results, not results of a completed test. Every step uses a sandbox or other simulated environment with payment, guest messaging, and courier dispatch disabled. The two time checks are separate attempts, each starting with a new draft.
| Simulated check | Expected result | Next action owner |
|---|---|---|
| Close the browser before submission; return after 15 minutes on the same phone. | The draft returns with its selections visible. The screen says it has not been submitted and asks the guest to review the table and items. | Guest reviews; staff helps if the draft is unclear. |
| Start a separate draft; return after 30 minutes. | The old cart is not presented as an active order. The guest sees a clear fresh-start or expiry message. | Guest starts again; staff can take the order if needed. |
| Return to a draft after a selected item has become unavailable in the simulation. | The guest is told what needs attention before submission; the unavailable item is not silently treated as ordered. | Guest changes the selection; staff offers an alternative if asked. |
| Guest cannot find the cart and asks whether the kitchen received it. | Staff can check the relevant order status using the vendor's demonstrated workflow, or explain that they cannot verify it there. | Staff checks or escalates to the shift lead before helping the guest reorder. |
Before running the worksheet, agree on what starts the expiry clock. Is it the first scan, the last cart edit, or another event? Also define what “return” means: reopening the existing tab is not necessarily the same as scanning a code again. If the vendor cannot configure the two intervals above, replace them with the actual settings and decide whether those settings suit service.
The last row matters even if the system normally restores drafts. A guest may hand the phone to a server and say, “I thought I ordered.” Train staff to look for a submitted order using the available status and order details. If the system cannot show enough to resolve the question, staff should involve the shift lead rather than guess. A paper or staff-entered order can be the fallback once the team has established the appropriate status.
Set a pass-or-fail test before purchase
Put the expected behavior in writing and ask the vendor to run it with you. Use a simulated menu, simulated table identifiers, and test order handling. Confirm with the vendor that the environment cannot take a real card payment, send a guest message, or dispatch a courier. Do not use a live guest's phone or order for the practice checks.
- Build and interrupt. Add an item and a modifier to a draft, then close the browser before submitting. Pass if the return behavior matches the agreed rule and the guest can identify the cart as unsubmitted. Fail if the screen suggests the kitchen has received an order when it has not.
- Check expiry. Run separate attempts just before and after the agreed expiry point. Pass if the documented behavior and message match the rule at both points. Fail if an expired cart appears to be a current order or the guest receives no understandable next step.
- Check an exception. Change an item's availability in the simulation before returning to the draft. Pass if the guest is prompted to resolve the issue before submission. Fail if the screen leaves the guest believing the unavailable selection has been ordered.
- Check table and status. Simulate a table change, then compare the draft screen with a separately simulated submitted-order screen. Pass if the guest can distinguish the two states and the agreed table-confirmation process works. Fail if staff or the guest must infer the state from the cart contents alone.
- Practice manual recovery. Ask a staff member to handle a missing cart using only the information and screens available during service. Pass if they can follow the agreed check and fallback without guessing. Fail if the process relies on access or information they do not have.
Record the device, browser, return path, timing, messages, and outcome for each attempt. Ask support: “If a guest closes the browser before submitting, what can our staff see, how long does the draft remain available, and who can help if it does not return?” Request the answer for your intended configuration and service hours.
A simulated check establishes whether the flow meets your stated criteria without affecting service. If it passes, a separate live service pilot can show whether staff can explain the flow under normal conditions. Plan that pilot with the vendor and staff, using genuine orders only through the normal authorized service process. Do not treat the simulation as proof of live performance.
Consider how the result fits the rest of your setup. Your restaurant POS system and staff workflow need a usable way to check submitted orders; a QR menu alone does not establish that workflow. For the broader choice of where phones fit alongside servers, see the guide to QR ordering in table service.
Next step: Choose your draft-expiry rule and the staff fallback, then compare your QR requirements with Fleksa. Ask the team to confirm feature availability and demonstrate the return and status screens for your setup.
Frequently asked questions
Does closing the browser submit the cart?
Do not assume it does. Ask the vendor to show exactly what action submits an order and how the guest and staff can distinguish a draft from a submitted order.
Should a restaurant always restore an unfinished cart?
No. Restoration can save guests from rebuilding a detailed order, but a fresh start may suit a short menu. Choose based on expiry, table confirmation, changed items, and the help staff can provide.
Can staff recover a cart for a guest?
That depends on the system and staff permissions. Ask what staff can see, whether they can assist with a draft, and what fallback they should use when the cart is unavailable.
