When one guest uses a phone to order for another, check three things before treating the order as ready: can the person submitting it identify the intended guest, can someone see a clear confirmation, and can staff match the order and payment status to the right handoff? A successful scan alone does not answer those questions.
Run the checks in a safe demonstration or test environment first. Then decide whether the workflow is clear enough for your service, needs a staff-assisted fallback, or should not be used for this situation. Features and screen behavior vary by provider and setup, so ask to see the actual flow you would use.
Map the people and the order before testing
Start with the people involved, not the device. One person may choose the food, another may enter and submit it, and a third may collect it. The phone owner is not necessarily the person eating or paying.
Hypothetical example: At table 6, Maya has a phone and scans the table code. Her guest, Theo, asks Maya to order a sandwich for him. Maya then wants to place a separate order for her own soup. The names, table number and items here are fictitious; they are inputs for a simulated check, not records of a real service.
Write down what must be clear at each step:
- Choosing: Theo chooses the sandwich; Maya enters it. Can she review the item and any requested changes with him before submission?
- Submitting: Maya submits the order. Is there a place to enter Theo's name or another useful identifier? If not, what will staff use instead?
- Confirming: Who sees the confirmation, and does it show enough detail for Maya to tell Theo what was sent?
- Handoff: Can the person delivering or calling the order identify Theo's sandwich without assuming Maya is the intended guest?
A table number identifies a physical table, not a person. It may be enough if staff deliver both items to the table and the guests sort them out. It may not be enough at a busy pickup counter, particularly if both orders contain similar items. Agree on the standard your staff need before deciding whether a name is necessary.
Check the code setup too. A code attached to the wrong table can make an otherwise clear order hard to deliver. Use the table QR code guide to review how codes are assigned, then ask your provider how the table identifier appears to staff in your setup.
Run a safe shared-device acceptance test
Ask the vendor for a demonstration or test environment that shows the guest flow and the staff view. Use fictitious names and items. Confirm with the vendor that the simulation cannot create a real payment, send a guest message or dispatch a courier. Do not enter real card details or contact information. If a safe simulation cannot show a step, leave that step unresolved rather than placing a real order as a workaround.
Begin at the same entry point a guest would use. Do not assume an account is required, or that it is unnecessary. Ask what the guest must enter and whether a later order on the same phone reuses any information. Fleksa's QR ordering lets guests scan, order and pay at the table in a browser without downloading an app; check the remaining shared-device details in the configuration being considered.
Use the following sequence for Maya and Theo. The acceptance criteria are the same whether the provider shows the result on a screen, in a test ticket or in another staff view.
- Scan the table 6 code. Confirm that the guest-facing flow identifies the intended table or provides another way to verify it.
- Enter Theo's sandwich. Look for an optional or required guest name, order note or other identifier. Use only a field the provider says is visible to the people handling the order.
- Review and simulate submission. Check whether the confirmation identifies the sandwich, the table or pickup point, and an order reference or other usable distinction. Note what payment status is displayed.
- Return to the ordering flow on the same phone and start Maya's soup order. Check whether Theo's name, items or other details carry over. If they do, establish whether Maya can correct them before submitting.
- Simulate the second submission. Verify that the two resulting orders can be distinguished from each other in the views needed for preparation and handoff.
Accept the simulated flow for this use only if the operator can verify both intended recipients or a workable table-level handoff, distinguish the orders, and determine what each confirmation and staff view says about payment. A guest name alone is not proof that an order was submitted or paid. A confirmation alone is not proof that staff can identify its recipient.
If a field is missing or a status is unclear, ask the vendor to show the alternative rather than assuming there is one. For example: “Where does the name entered here appear on the staff side?” and “What does the guest see if the order is submitted but payment has not been completed?” Record the answer and the screen or ticket where it appears.
Check two orders from one device on the staff side
Now look at the simulated results as a server, kitchen worker and pickup attendant would. The useful identifier must reach the person who needs it. A name visible only to the guest may not help a runner holding two plates.
The table below sets out the decision points for the hypothetical table 6 check. It describes what to look for, not a promise that every system displays these fields.
| Check | Acceptable result for this scenario | If it is unclear |
|---|---|---|
| Theo's order | Sandwich and table 6 are identifiable; a name or agreed handoff method connects it to Theo. | Use staff assistance to confirm the intended recipient. |
| Maya's order | Soup is distinguishable from the sandwich order, without a misleading carried-over name. | Correct the identifier if possible, or use staff assistance. |
| Confirmation | Maya can see which order was submitted and explain it to the intended guest. | Ask staff to verify the order before repeating it. |
| Payment status | The guest and staff can tell the displayed status for each order before handoff. | Staff verify the status through the restaurant's normal process. |
Ask whether the staff view shows two separate tickets, order references, timestamps or another distinction. Do not rely on a timestamp alone if two similar orders could arrive close together. Also check whether instructions entered by the guest appear where food is prepared, where it is handed over, or both. A note that never reaches the handoff point cannot serve as the sole identification method there.
Pay special attention to payment wording. “Order received,” “payment pending” and “paid” answer different questions. If the demonstration displays a status, ask what action causes it to change and who can see it. A simulated status demonstrates the screen flow; it does not prove a real transaction was processed.
Finally, check what happens if Maya does not see a confirmation. The safe guest instruction is to ask staff to check before submitting again. That reduces uncertainty without assuming the first submission failed or promising that a duplicate can always be prevented.
Set a fallback and make the buying decision
Give staff a short route for ambiguous cases. A server can ask for the table, the item and the intended guest, then check the restaurant's order view before taking further action. If the system cannot distinguish the orders adequately, staff can take or enter the order through the restaurant's established assisted process instead. Confirm the payment status through that process; do not tell staff to infer payment from the presence of food on a ticket.
Keep the guest instruction simple: “If you're ordering for someone else, check the name or tell your server who the food is for. If you don't see a confirmation, ask us before ordering again.” Adjust the wording to match fields and staff procedures your setup actually supports. Offer the same staff-assisted route to a guest who does not want to use a phone.
For the hypothetical example, a reasonable decision is to use the shared-phone flow when the simulated orders are distinguishable, confirmation is visible, payment status can be checked, and staff have a reliable handoff method. If table-level delivery is the agreed method, names need not carry the whole process. If the restaurant calls individual orders at a counter and staff cannot identify recipients, use the assisted route until the vendor demonstrates a workable alternative.
A simulation is a screen and workflow check, not evidence of how staff will perform during a rush. If the simulation passes, plan a separate, supervised live service pilot using your normal ordering and payment procedures. Brief staff on the fallback, watch for unclear handoffs, and review what needs to change afterward. A live pilot can reveal service issues that a demonstration cannot; it does not guarantee every order will be handled correctly.
Before signing, compare the workflow with the service you actually run. A QR menu alone is not necessarily ordering and payment software. Ask for a written quote that separates platform charges from processing and any other applicable costs. Fleksa's plans page is the place to check current pricing; pricing information was checked in November 2026. For broader placement decisions, see the guide to where QR ordering fits in table service.
Next step: Ask Fleksa to walk through the two-order shared-phone scenario and compare the relevant workflow and current availability for your restaurant.
Frequently asked questions
Does each guest need a separate phone?
Not necessarily. The important question is whether the chosen workflow lets guests and staff distinguish the orders and handle confirmation and handoff clearly. Check the provider's actual flow.
Is the table number enough to identify an order?
It can be enough when staff deliver to the table and guests can sort out the items. For individual pickup, staff may need a name or another reliable identifier.
What should staff do if the guest cannot find a confirmation?
Check the restaurant's order view before asking the guest to submit again. Verify the order and payment status using the normal staff process, then help the guest with the next step.
