When a guest is unsure whether a QR order went through, ask them to pause before tapping submit again. A staff member should check the order record, payment state, and kitchen status first. If the result is still unclear, involve a manager rather than guessing or asking the guest to pay again.
The aim is to prevent two separate problems: preparing the same food twice and taking payment twice. An order can have reached the kitchen even when the guest never saw a confirmation. A payment can also be pending while the order itself needs investigation. Treat those as separate checks.
Find out where the guest got stuck
Start with a calm question: “What happened after you tapped submit?” The guest may have seen a spinning screen, a payment prompt, an error, or nothing at all. Ask roughly when they tried, what they ordered, and whether they saw a confirmation or order number. Don't ask them to share a full card number.
Note the physical table or QR location and how many people are in the guest's party. One physical table can have several separate parties or orders, and one party can submit more than one order. Table number alone is not enough to identify a match.
Keep the guest's screen available if they are comfortable doing so. A refresh, a second tap, or a new payment attempt may make the situation harder to untangle. Tell them you are checking with the kitchen and will return with an update. Give the kitchen a way to reach you while the check is underway.
Before service, map the points where uncertainty can arise in your own setup: the submit button, payment step, confirmation screen, staff order view, and kitchen ticket. Ask the provider what each screen displays when a request is delayed or interrupted. The goal is to know which view staff should trust for each part of the decision, not to assume that one screen tells the whole story.
A QR ordering flow can let guests scan, order, and pay at the table in a browser. That is different from a QR menu that only displays items. When comparing tools, establish exactly where an order becomes visible to staff and what the guest sees at that moment.
Check the order and payment before a retry
Search the staff order view using the strongest details available: an order number, approximate time, table or location, and item list. Compare modifiers and quantities as well as item names. Two burgers at the same table could be a legitimate second order; two identical orders entered seconds apart deserve a closer look.
If you find a likely match, open it and check its status. Then ask the kitchen whether it has received, started, or completed the ticket. A restaurant POS system and a kitchen display system may be part of that handoff; ask how your chosen setup connects their order views and how quickly changes appear.
Check the payment record separately. A visible payment attempt, a pending authorization, a completed payment, and a refunded payment are not interchangeable. Don't tell a guest they have been charged or refunded until an authorized staff member can verify the relevant state. If the order is found but payment is unclear, preserve the order details and escalate the payment question instead of creating another order.
If no matching order appears, don't immediately conclude that nothing was submitted. Check the relevant time window and location, then ask whether delayed orders can arrive after the initial search. Follow the provider's recommended method for confirming that a retry is safe. If staff cannot establish the state, a manager should decide how to resolve it with the guest and monitor for a late ticket.
Use these questions in a vendor demonstration:
- Does the system recognize a repeated submission as the same attempt? What happens if the guest refreshes, changes devices, or taps twice?
- What identifier links the guest's attempt, the order record, the payment record, and the kitchen ticket?
- Which statuses can staff see when an order or payment is pending, failed, completed, voided, or refunded?
- Can an order arrive after the guest sees an error? How should staff check for a delayed arrival before retrying?
- What permissions and steps are required to stop preparation, void an order, or resolve a duplicate payment?
Use a decision worksheet during service
The following examples are hypothetical. In each case, one party at physical table 8 says it submitted one order for two sandwiches and a drink. The party has not intentionally placed a second order. The worksheet changes the staff response as the evidence changes; it does not assume that a particular system provides every status shown.
| What staff find | Kitchen state | Payment state | Next action |
|---|---|---|---|
| One matching order | Received; not started | Completed | Confirm the order with the guest. Do not resubmit. Let the kitchen proceed once the match is verified. |
| One matching order | Started | Pending or unclear | Do not resubmit. Tell the kitchen a payment check is underway and ask a manager to resolve it. |
| Two matching orders close together | One started; one not started | Two attempts visible; final states unclear | Ask the kitchen to hold the second ticket. Confirm the intended quantity and escalate both payment records before any void or refund. |
| No match after the initial search | No ticket found | Unknown | Check the provider's delayed-order procedure and escalate if the state remains uncertain. Retry only when authorized and safe. |
The important change between the first and third rows is not the table number. It is the number of matching records and whether preparation has begun. In the third row, stopping the unstarted ticket may prevent extra food, but it does not settle whether either payment needs action. In the last row, a missing search result is a reason to investigate, not proof that a retry is harmless.
Adapt the worksheet to the screens and permissions your team actually has. Assign a named role to check orders, another to communicate with the kitchen, and a manager or other authorized person to handle payment exceptions. On a small shift, one person may fill more than one role, but the handoff still needs to be explicit.
Escalate to the kitchen and resolve duplicates
When two possible tickets appear, send a clear hold request: identify the table, order details, and the specific ticket that may be a duplicate. Ask the kitchen to acknowledge the hold. A verbal “we might have a duplicate” without a ticket identifier can stop the wrong meal or be missed during a rush.
Confirm the guest's intended order before canceling anything. A party may have deliberately ordered the same item twice, or a second person at the same physical table may have placed a separate order. Compare the time, quantities, modifiers, and any available order identifiers. If the evidence conflicts, keep the manager involved.
Once the duplicate is established, follow your system's authorized void or cancellation process. Ask the kitchen to confirm what it stopped and what it has already prepared. Then check each payment separately and use the appropriate process for its actual state. A voided kitchen ticket does not by itself prove that a payment was reversed.
Record enough for the next shift or manager to follow the issue: the time, table, order identifiers, action taken, kitchen acknowledgment, and payment status or unresolved question. Keep sensitive payment details out of informal notes. Close the loop with the guest in plain language: explain which order is proceeding and who will follow up on any payment question.
Practice the retry decision without live transactions
Before rollout, ask the provider for a demonstration or safe training environment that shows uncertain submission, delayed confirmation, duplicate tickets, and payment states. Use simulated records or a walkthrough. Practice must not create a real card payment, send a guest message, or dispatch a courier. Confirm those safeguards before anyone starts.
Give staff a short scenario without telling them the answer. For example, show a simulated confirmation delay and one matching kitchen ticket. The expected response is to identify the existing order and avoid resubmitting. In a separate scenario, show no immediate match and an unresolved payment state; the expected response is escalation and a delayed-order check, not an automatic retry.
Run another scenario with two similar tickets and have the team identify which one to hold, obtain kitchen acknowledgment, and describe who can resolve the payment. Check the handoff aloud: can the person receiving the request identify the ticket without relying on table number alone? Note where staff have to leave one screen, ask someone else, or wait for a status update.
A live service pilot is different from a simulation: real guests can place real orders. If you choose to run one, brief staff beforehand, assign an escalation contact, and use your normal payment and guest communication procedures. Do not manufacture a duplicate or ask a guest to make an extra payment to test the workflow. Review genuine exceptions afterward and adjust the process.
For a broader look at where this service model fits, see the guide to QR ordering in table service. Fleksa's plans page, checked November 2026, is a starting point for current pricing; ask for a quote that covers your intended setup and processing costs.
Next step: Bring the worksheet and your escalation questions to a Fleksa QR ordering conversation. Ask the team to walk through an uncertain submission using your table-service workflow before you decide.
Frequently asked questions
Should a guest submit again if no confirmation appears?
Not immediately. Ask staff to check the order, payment, and kitchen states first. If the result remains unclear, escalate and follow the provider's delayed-order procedure before authorizing a retry.
Does canceling a duplicate ticket refund the guest?
Not necessarily. Kitchen and payment actions are separate. An authorized staff member should check each payment record and use the appropriate void or refund process for its state.
How can staff practice without charging anyone?
Use a provider demonstration, simulated records, or a walkthrough with safeguards against real payments, guest messages, and courier dispatches. Treat any later live service pilot as real service, not as a simulation.
