Track a partially served QR order as a list of items still owed to the table, not simply as an order that has been accepted. For each item, staff need to know what was ordered, whether it has reached the guest and who owns the next action. Keep the order open in the team's working view until the final item is served or its exception is resolved.
That distinction matters when a drink arrives quickly but food takes longer. A ticket marked “complete” too early can make an outstanding dish disappear from the runner's view. A ticket left open without item detail can prompt someone to deliver the same drink twice. The right buying decision depends on how clearly the system supports your actual handoff, including what staff must track outside the screen.
Map the order from acceptance to service
Start with the full path through your dining room. Fleksa's QR ordering lets guests scan, order and pay at the table in a browser. After an order is accepted, however, the operational question is how your team will track the separate items as they move through preparation and service.
Hypothetical example: A guest at table 8 orders one iced tea, one sandwich and one soup. The drink is delivered first. The sandwich is ready next, while the soup is delayed. This is one order for one physical table, with three items that can reach the guest at different times.
Use the worksheet below to define what staff should see or record. “Served” means delivered to the guest, not merely prepared or picked up. The example describes a desired workflow, not a claim that a particular product provides these statuses.
| Item | Current situation | Next action | Owner |
|---|---|---|---|
| Iced tea | Served | Leave marked as served; do not send again | Runner records delivery |
| Sandwich | Ready, not yet served | Take to table 8 and record delivery | Runner |
| Soup | Delayed, not served | Check timing and keep visible as outstanding | Kitchen lead coordinates with server |
The worksheet separates a preparation state from a service state. That matters because a sandwich on the pass is not yet at the table. It also assigns an owner: a delay with no named follow-up can sit unnoticed even when the ticket remains visible.
Before evaluating screens, decide how staff identify the order. The table number should be easy to match to the physical table, and the order should remain distinguishable if another party orders from that table later. Decide who updates the record, when the update happens and how the team handles a guest who moves tables.
Compare item-level and whole-order completion
An item-level view is useful when staff can see and update individual items without losing sight of the rest of the order. In the example, the team could identify the iced tea as served, the sandwich as awaiting delivery and the soup as outstanding. Ask the vendor which statuses are available, who can change them and whether a change appears to everyone who needs it.
Do not assume an item marked “ready” is also marked “served.” Ask whether the system distinguishes those events, or whether staff need another way to record the handoff. Also ask whether completing one item changes the visibility of the remaining items on the order.
A whole-order view can work when your service is simple and someone reliably maintains the item detail elsewhere. The order stays open until all three items are served or the remaining issue is resolved. The tradeoff is that an open ticket alone does not tell a runner whether the drink has already gone out. A paper check or shared handoff note must carry that detail.
Compare both approaches against a busy shift, not just a quiet demonstration:
- Visibility: Can a runner see what is still owed without asking the kitchen to reconstruct the order?
- Updates: Can the person who delivers an item record it at the point of handoff, or must someone else do it?
- Closure: What happens when the last item is served? Can an incomplete order be closed accidentally?
- Exceptions: How are a canceled item, a replacement or a disputed delivery recorded without hiding the remaining work?
- History: Can a manager understand the sequence later if a guest asks about a missing item?
Review the flow across the restaurant POS system and any kitchen screen you plan to use. A kitchen may need preparation information while a runner needs delivery information; a single completion button may not answer both needs. Ask the vendor to show the actual configured views rather than assuming the same status means the same thing on every screen.
If item-level service updates are available and easy for runners to use, they may reduce reliance on a separate checklist. If they are not, a whole-order view plus a disciplined manual record may be enough for a small team. Choose based on whether staff can reliably identify the remaining items during service, not on the number of status labels in a demo.
Test the handoff when an item is delayed
Write acceptance criteria before a demonstration. For the example order, the criteria are: the team can identify table 8; the drink can be recorded as served without closing the order; the sandwich remains identifiable until delivered; and the delayed soup remains visible until served or otherwise resolved. If the software cannot record one of those states, identify the manual record that will do so.
Run a simulation with staff acting as the kitchen, runner and server. Use a demo or training environment, or a clearly marked paper ticket. Do not trigger a real card payment, guest message or courier dispatch.
- Enter or write the example order and confirm the table identifier. Have the kitchen participant acknowledge all three items.
- Simulate delivering the iced tea. The runner records it as served using the intended system or fallback. Check that the food remains outstanding.
- Simulate the sandwich becoming ready while the soup is delayed. The runner identifies and delivers only the sandwich, then records that delivery.
- Have the server check the remaining order without help from the person who made the last update. The server should find the soup, its delay and the person responsible for following up.
- Simulate the soup being served, or explicitly resolved another way. Only then close the order in the working record.
Record a pass only when each criterion is met with the steps staff would actually use. If a participant has to guess, rely on memory or ask the original runner, note the gap and assign a change before trying again. Time pressure matters, but accuracy and a clear owner matter more than a fast tap.
Separately, a live service pilot can check whether the agreed process holds up during a real shift. Brief the team, choose who monitors outstanding orders and review any missed or unclear handoffs afterward. A simulation prepares staff; it does not establish how the workflow performs with actual guests and kitchen interruptions.
If you use a kitchen display system, include the kitchen's view in the demonstration. Ask how a delayed item stays visible, what a bump or completion action affects, and what the runner sees afterward. The goal is a shared understanding of what remains to be served, even if the kitchen and front of house use different views.
Set a manual check for missing item status
If the system only shows an order as open or complete, create one authoritative item checklist. It can be a printed ticket or another shared record your team already uses. Put the table identifier, order identifier, items and any relevant modifiers on it. Mark each item only after delivery, and keep the ticket in a designated outstanding-order location until every line is resolved.
Assign the runner to mark deliveries and the server or shift lead to review outstanding tickets. For a delayed item, write the next action and the person responsible. If the kitchen changes an item or a guest cancels it, record that outcome rather than marking it served. A replacement should be identifiable as a replacement, so the team does not mistake it for an extra dish.
Make the check part of the handoff: before leaving the pass, the runner reads the destination and items; after delivery, the runner marks the record. When responsibility changes between staff, the outgoing person points out any outstanding lines. At order closure, the server checks that no unserved item remains without an explanation.
A manual system has limits. Tickets can be misplaced, marks can be delayed and two people can update different copies. Keep one working copy, choose a visible location and give a shift lead responsibility for resolving disagreements. If that routine is too cumbersome at your volume, treat better shared item visibility as a buying requirement rather than an optional extra.
Payment status is a separate check. A paid order can still have food outstanding, and a served item does not establish whether payment was completed. Ask how staff can see payment status without treating it as proof of service. For broader choices about where guests order and how staff assist them, use the guide to fitting QR ordering into table service.
Next step: Take the worksheet and acceptance criteria to a vendor demonstration. Compare your QR requirements with the workflows available from Fleksa, and ask the team to show how an outstanding item stays visible through the runner handoff. Start with Fleksa QR ordering.
Frequently asked questions
Should staff close a QR order when the first item is served?
Keep it open in the team's working record until every item is served or its exception is resolved. If the software uses a different completion rule, maintain a separate outstanding-item record that staff can check.
Is a kitchen-ready status the same as served?
No. Ready means an item is available for pickup; served means it reached the guest. Decide who records each event and how the runner communicates delivery to the rest of the team.
What if the QR system cannot track individual items?
Use one shared ticket or checklist alongside the open order. Mark each delivery, identify delayed items and assign a person to follow up. Test the routine with staff before relying on it during service.
