A runner needs enough information to find the right destination, carry the right items, and know what to do when the recipient is unclear. At a minimum, evaluate whether the handoff shows the table or pickup destination, service area, items, and a useful order reference. Depending on your service model, it may also need a guest identifier, item modifiers, and timing or release status.
The buying question is not just whether guests can order by phone. Ask what the runner actually sees, where that information appears, and whether it remains useful when several orders are ready at once. A QR menu alone does not necessarily take orders or payments.
Follow the order from phone to runner
Start with the route an order takes in your restaurant. A guest scans a code, chooses items, and submits an order. The order must then reach the people preparing it. When food is ready, someone needs to connect the prepared items to a destination and release them to a runner.
Draw those steps on paper before looking at a demo. Mark where staff will read the order: a kitchen display, a printed ticket, a POS screen, or another handoff screen. Ask the vendor which fields appear at each point. A detail visible to the guest or cashier may not be visible to the runner at the pass.
Fleksa's QR ordering lets guests scan, order, and pay at the table in a browser without downloading an app. For the runner handoff, ask which destination, item, and status details your intended setup can display or print. Confirm the answer for the devices and service configuration you plan to use.
Also decide who checks an order before it leaves the pass. The cook may know the items are ready, while an expediter or server may be better placed to resolve destination questions. If one person fills both roles, make that responsibility explicit. The runner should not have to guess which screen holds the missing information while food gets cold.
Build a ticket a runner can use
The following is a hypothetical ticket for an order placed by a guest sitting at a table. It is a buying worksheet, not a claim about the fields or output of any particular product. Assume the restaurant uses an expediter at the pass and identifies the patio as a separate service area.
| Ticket detail | Example | Why the runner needs it |
|---|---|---|
| Destination | Table 12, patio | Points to a physical table and the area in which to find it. |
| Order reference | Order P47 | Lets the runner and expediter refer to the same order. |
| Items | One veggie burger, no onion; one fries; two lemonades | Helps staff check the tray and preserve the item's modifier. |
| Timing and release | Submitted 12:08; food released 12:20 | Shows when the order entered the flow and when the food was cleared to run. |
| Recipient detail | No guest name or seat shown | Tells the runner to deliver to the table, not assume which guest ordered. |
The decision in this example is to take the released food to table 12 on the patio and confirm the items with the party there. The table and area identify the destination; they do not identify the individual who ordered the burger. The modifier helps distinguish the dish, but it does not replace a conversation with the guests.
The timing fields also have different jobs. Submission time can help staff understand how long an order has been in the workflow. Release time tells the runner that the food is ready to leave the pass. Ask whether the system provides either time, who sets a ready or release status, and whether the runner can see it. A timestamp alone does not prove every item is ready.
Check how drinks fit into the handoff. If a bartender runs the lemonades separately, the runner needs to know whether the food ticket represents the whole order or only the food. If the ticket cannot show that distinction, agree on a staff process at the pass. Otherwise, a runner may wait for drinks already delivered or assume they are coming when no one has taken responsibility.
Compare table-only and guest-level details
A table destination can be enough when one party occupies the table, the runner can speak with guests, and the order can be safely matched at the table. It is less helpful when several guests at the same table place separate phone orders, when guests move, or when a shared table has more than one party.
A guest name, seat number, or other identifier may make the last step easier, but only if staff and guests use it consistently. Ask whether guests enter a name, whether staff assign seats, and which of those details appear on the runner's view. Do not assume that an identifier collected during ordering carries through to a kitchen ticket.
Consider the tradeoff before requiring extra information. Names can be misspelled or shared. Seat numbers need a clear convention and may become stale when guests change seats. A runner should still confirm an uncertain dish rather than treat any one field as proof of the recipient.
The destination itself also needs to be understandable in the dining room. A label that makes sense in the ordering system should match what staff call the physical table and area. Review the setup process for table QR codes, then ask how a destination appears to staff after an order is submitted. This check is about the handoff, not just whether a code opens the right menu.
For counter pickup, a table number may not be the right destination at all. Ask how a runner or pickup attendant distinguishes orders and calls or finds guests without exposing more personal information than the service requires. For table service, decide what happens if a guest cannot use a phone; an employee-assisted order should still reach the appropriate preparation and delivery workflow.
Simulate a split order and an unclear destination
Before buying or changing the live workflow, walk through the hypothetical ticket with the staff roles who would handle it. Use a vendor demonstration or a practice environment with fictitious data. Make sure the exercise cannot charge a card, send a guest message, or dispatch a courier. Do not use a real guest's order as practice.
- Check the pass. Show the expediter the burger, fries, and two drinks on the sample ticket. Ask what must be present before the food is released and how staff will mark or communicate a separately prepared drink.
- Check the runner view. Give the runner only the screen or ticket they would normally use. Can they find the patio, identify table 12, read the modifier, and refer back to order P47?
- Introduce ambiguity. Say the runner reaches the patio and finds two parties sharing table 12. The ticket has no guest name or seat. The runner should not choose a party based on appearance or leave the food without confirmation.
- Trace the resolution. Have the runner return to or contact the designated expediter. The expediter checks the available order details and, if needed, asks the server responsible for the area to identify the party. If staff still cannot establish the recipient, keep the order at the pass while the team resolves it.
Record what the runner could see without help and what required a conversation. A successful simulation means the team followed the agreed handoff and escalation; it does not establish how the workflow will perform during a busy service. If the demonstration omits a field your process depends on, ask whether it can be configured for the runner's actual view. If not, decide whether a staff step is reliable enough before accepting the workflow.
A separate live service pilot can reveal practical issues such as congestion at the pass or staff switching between screens. Run one only after setup and responsibilities are agreed, with real orders handled through your normal operating procedures. Review unclear deliveries and missed handoffs with the team afterward. Do not treat a practice order as a live guest order.
Assign the escalation before service
Give the runner one clear first contact for an unclear destination: for example, the expediter at the pass. Give that person a second contact, such as the patio server, when the order details alone cannot identify the party. Agree where the food waits and who updates the runner once the question is resolved.
Use the order reference in that conversation. “Where does P47 go?” is more precise than “Who ordered the burger?” The expediter can compare the reference, destination, items, and any available recipient detail without sending the runner back and forth between tables. If an item or modifier is unclear, return it to the preparation team for clarification rather than asking a guest to resolve an incomplete kitchen handoff.
Before committing, ask the vendor to demonstrate the full path for your service model: guest submission, preparation view, release, runner view, and resolution of an ambiguous order. Include the phone-free fallback and ask who can correct a destination if a guest moves. The guide to where QR ordering fits in table service can help you decide which staff responsibilities remain at the table.
Next step: Bring the sample ticket and your escalation plan to a Fleksa conversation. Compare the QR workflow and current availability with Fleksa, and ask to see the exact information your runner would receive.
Frequently asked questions
Is a table number enough for a food runner?
It can be enough when the physical table and service area are clear and the runner can confirm the order with the party. Shared tables, separate orders, and guest movement may require another identifier or help from staff.
Should a runner see payment status?
That depends on your handoff rules. Decide whether staff must check payment before food is released, who performs that check, and what happens when status is unclear. Ask the vendor where the status appears rather than assuming it is on the runner ticket.
How can we practice without affecting guests?
Use fictitious orders in a demonstration or practice environment configured so no real payment, guest message, or courier dispatch occurs. Walk through the handoff and escalation separately from any later live service pilot.
