To distinguish a submitted QR order from one that never reached the kitchen, staff need to see the last confirmed step and know who can check the next one. A guest’s screen may show that they tapped submit, but that alone does not establish that the restaurant accepted the order or that the kitchen received it.
Build the handoff around an order identifier, a physical table number, a clearly named status and an owner for each check. When the status is uncertain, the server should check for an existing order before asking the guest to submit again. That reduces the chance of a duplicate while giving the guest a clear update.
Define what each order status means
Before comparing screens, agree on the moments your team needs to distinguish. A useful status map has four boundaries:
- Guest submission: The guest has attempted to send the order. Ask what appears on the guest’s screen and whether it identifies a specific order.
- Restaurant acceptance: The restaurant’s system has recorded or accepted the order according to the vendor’s definition. Ask whether acceptance is automatic or requires a staff action.
- Kitchen receipt: The order has reached the kitchen’s designated work queue or device. Ask what evidence the front-of-house team can see, and whether someone must check the kitchen directly.
- Delivery to the table: Staff have brought the items to the guest. Decide who marks this step, if your chosen system supports it, and how partial deliveries are handled.
Those boundaries are not interchangeable. An order can be accepted but still need a kitchen check. A payment confirmation may establish a payment state, but it does not by itself prove that food is being prepared. Likewise, a guest saying “I ordered” is a useful starting point, not a complete status record.
Ask each vendor to define its labels in plain language. Does “sent” mean sent by the guest, accepted by the restaurant, or delivered to a kitchen device? What does the screen show if the next step is delayed or unknown? Avoid building a procedure around a label until staff know exactly what it confirms.
A QR menu alone may only show food and prices. Ordering, payment and staff notification are separate parts of the workflow to verify. Fleksa’s QR ordering lets guests scan, order and pay at the table in a browser without downloading an app. For any system, ask how the handoff appears to staff in your intended setup.
Build a staff view around the last confirmed state
The most useful front-of-house screen answers three questions quickly: which physical table is involved, which order is in question, and what happened last? A table can have more than one guest party or more than one order, so a table number alone may not identify the right request.
Use this handoff map as a starting point for a vendor demonstration and your own service procedure. The owners are suggested roles; adapt them to the way your restaurant is staffed.
| Boundary | Evidence to look for | Owner and next action |
|---|---|---|
| Submission attempted | Guest screen, table number and any order identifier | Server checks whether a matching order exists |
| Restaurant accepted | Matching order record and the vendor’s defined acceptance state | Server checks the next state or contacts the kitchen |
| Kitchen received | Kitchen queue confirmation or direct confirmation from kitchen staff | Kitchen lead confirms receipt; server updates the guest |
| Food delivered | Staff confirmation of items brought to the table | Runner or server notes any missing items and follows up |
The map deliberately separates evidence from ownership. If the staff screen cannot confirm kitchen receipt, the kitchen lead’s check becomes part of the procedure rather than a step the server assumes has happened. If a runner delivers only some items, the server needs to know what is still outstanding rather than treating the entire order as complete.
During a demonstration, ask the vendor to show how staff would find an order by table and identifier, see its last confirmed state, and identify when that state changed. Ask whether the view shows payment status separately from order status. Can staff distinguish two orders from the same table? What happens if a guest scans the wrong table code or moves tables?
Also ask how an alert reaches the person responsible for acting on it. A notification that appears only on a device nobody watches during the rush may not solve the handoff problem. Confirm whether alerts can be acknowledged, what happens when they are missed, and how staff find unresolved orders later. These are evaluation questions, not features to assume are included.
If you use a restaurant POS system, ask how its order record relates to the QR order and kitchen workflow. Have the vendor identify which screen is the source of each status and which staff roles can view it. For a broader decision about how QR fits alongside table service, use the related buying guide.
Check an ambiguous submission before a retry
Consider this hypothetical example: a guest at physical table 8 says they submitted a drink and an appetizer. Their phone no longer shows a clear confirmation. The server cannot tell from the guest’s description whether an order exists.
- Pause the retry. Tell the guest you are checking for an existing order first. Do not ask them to submit again while the original could already be in the system.
- Collect identifying details. Note the physical table, the items, the approximate submission time and any order identifier the guest can show. Avoid relying on the table number alone if the table has multiple parties or orders.
- Check the restaurant record. Look for a matching order and read the last confirmed state. If a record exists, compare its items and table details with the guest’s request.
- Check the kitchen when needed. If the record does not establish kitchen receipt, the assigned staff member asks the kitchen lead to check the designated queue. Do not infer receipt from a payment or acceptance label.
- Check payment separately. If the guest attempted to pay, establish what the payment record shows before taking another payment. Ask a manager to handle an uncertain payment according to the restaurant’s procedure.
- Agree on the next action. If the order is found, explain its known state and follow up on the missing handoff. If it cannot be found after the appropriate checks, offer a staff-assisted order or a retry under the restaurant’s procedure.
For the example, suppose the restaurant record shows an accepted order matching both items, but the front-of-house view does not show whether the kitchen received it. The server asks the kitchen lead to check. If the kitchen confirms receipt, the server tells the guest the order is with the kitchen. If the kitchen cannot find it, the manager decides how to place or resend the order using the available workflow, after checking for duplicates and payment status.
If there is no matching restaurant record, that does not automatically explain what happened on the guest’s phone. The practical decision is whether the team has checked enough places to take a new order safely. Give the guest a non-phone option, such as ordering with the server, when the QR route remains unclear or the guest prefers not to use it.
Practice this sequence in a simulation before relying on it in service. Use a vendor-provided test environment or a paper walkthrough with fictional order details. Confirm in advance that the exercise cannot trigger a real card payment, guest message or courier dispatch. If a safe test environment is unavailable, use the paper walkthrough rather than placing a live practice order.
A live service pilot is different: it involves real guests and real orders. If you choose to run one, assign a manager to monitor the handoff, brief staff on the fallback, and decide how uncertain orders will be resolved. Do not treat a simulation as proof that every live notification or kitchen connection will work.
Assign escalation ownership before service
The server should normally own the guest conversation because the guest needs one person to return with an answer. The kitchen lead should own the kitchen check. A manager should resolve uncertainty that crosses roles, particularly a possible duplicate, an unclear payment or a disagreement about whether an order should be sent again.
Make the trigger for escalation specific. For example: if the server cannot match the guest’s details to a restaurant record, or cannot establish kitchen receipt from the available view, contact the designated lead rather than waiting without an update. Set an internal response target that fits your service, and make sure staff know what to do if that person is busy.
The guest update should describe what is known and what happens next: “I found your order and am checking with the kitchen,” or “I cannot confirm the order yet; I’m asking the manager to check before we place it again.” Avoid saying the kitchen has it until someone or something has confirmed that boundary.
Before buying, put this map beside the vendor demonstration. Ask the vendor to show your team how an uncertain table order would be found, who can see each state and how the kitchen check works in your setup. Compare those answers with your requirements when evaluating restaurant management software.
Frequently asked questions
Does a guest payment confirmation mean the kitchen has the order?
Not necessarily. Payment and kitchen receipt are different states. Check the order record and, when receipt is not visible, ask the kitchen to confirm.
Should a guest submit the QR order again if nothing appears?
Check for a matching order first, including its table, items and any identifier. If payment was attempted, check that separately before taking another payment or placing a replacement order.
Who should update the guest about an uncertain order?
Assign one front-of-house person, usually the server, to own the update. The kitchen lead checks the kitchen queue, while a manager handles unresolved duplicates or payment uncertainty.
