To prevent missed or repeated items, give staff one reliable way to see what each table has ordered, what has reached the kitchen or bar, and what has been paid. If server and QR orders do not appear in the same view, assign someone to reconcile the two records before sending a repeat item or closing the table.
The key buying question is not simply whether both ordering methods exist. Ask whether they share a table identity and item status, and what staff must do when they do not. A QR menu alone does not necessarily let guests place or pay for an order.
Map a drink and a meal through both paths
Start with the service you actually run. A server may take a drink order while a guest scans a code and orders a meal. Both actions belong to the same physical table, but they may start on different screens and produce different tickets.
Fleksa's QR ordering lets guests scan, order and pay at the table in a browser without downloading an app. When comparing any system, ask the vendor to show how that guest order relates to an order entered by staff. Do not assume that two available ordering methods automatically share a check or a live item view.
Hypothetical example: A party sits at table 6. A server enters one iced tea; a guest uses the table's QR code to order one sandwich. The restaurant wants each item prepared once and accounted for before the party leaves.
Trace the iced tea from the server's entry screen to the bar or other preparation point. Then trace the sandwich from the guest's confirmation screen to the kitchen. For each item, identify the table number, the time it was submitted, its preparation status and its payment status. Ask who can see each detail when the original server is busy.
Table identity needs particular attention. Is the code permanently assigned to table 6, or does a guest select a table? What happens if a code is moved, a table is renumbered, or two parties use the same physical table at different times? A table number alone may not identify the right party after turnover. Ask how staff close the first party's session before the next party starts.
Also plan for the guest who does not want to use a phone. The server should be able to take that order through the restaurant's normal staff process. Establish whether that process enters the same record as a QR order or creates a separate record that needs reconciliation.
Compare one shared view with separate tickets
A shared view can reduce the number of places a server must check, provided it shows both entry paths with enough detail to make service decisions. A screen that displays only a combined total is not enough to tell whether the iced tea was sent, changed or paid for.
Separate tickets can still work, but the restaurant needs a repeatable handoff. Someone must look at both records, match them to the correct party and resolve differences. That work matters most during a rush or when a server takes over another section.
Use this worksheet during a demonstration. The entries describe decisions and checks, not a promise that a particular product supports either workflow.
| Decision point | Shared-view option | Separate-ticket option | Acceptance check |
|---|---|---|---|
| Identify the party | Both entries appear under the same table and current party. | Each ticket carries a table identifier and enough context to match the party. | Staff can distinguish the current party from an earlier party at that table. |
| See ordered items | Iced tea and sandwich are visible together with their source and status. | Staff consult the staff-order and QR records. | A second server can name both items without asking the guest to reconstruct the meal. |
| Send to preparation | Each submitted item has a visible preparation handoff. | Each ticket has a clear destination and handoff status. | The practice record shows one intended preparation instruction per item. |
| Close the check | Staff can identify unpaid items and any payment already recorded. | Staff reconcile both records before presenting or closing a bill. | No paid item is requested again and no unpaid item is overlooked. |
Read the last column as the outcome your team needs to verify, regardless of which option a vendor offers. If the shared view cannot show item or payment status, it may still leave staff doing the same investigation as separate tickets. If separate tickets are the only practical fit, decide whether the extra check is manageable at your busiest service.
Ask the vendor to demonstrate the workflow using your menu and service roles. Show the staff-facing screen, not just the guest screen. If you use a restaurant POS system and a kitchen display system, ask exactly where each order appears and whether an integration or manual step is required. Confirm the setup and permissions in your quote rather than assuming that every connection is available.
Test changes and the handoff before payment
An initial order is only part of the job. A guest may change an item, ask a server to add a modification or decide to pay on the phone while a server is preparing the bill. These moments create opportunities for an item to be made twice or charged twice.
Run a simulated check with the vendor or your team before using the workflow in service. Use practice records and a safe test environment. The simulation must not trigger a real payment, guest message or courier dispatch. Make sure any practice kitchen or bar instructions are clearly marked and do not enter a live production queue.
- Enter the iced tea through the staff path and submit the sandwich through the guest path for the same practice table. Verify that the receiving records identify both items and their intended destinations.
- Ask a second staff member to take over the table. Without help from the first person, have them find both items and explain which have been sent for preparation.
- Simulate a sandwich change before preparation, then a cancellation after the original instruction has been sent. Check what the guest, server and kitchen can see. Establish who must tell the kitchen if an update is not delivered automatically.
- Simulate a payment status for one item and leave the other unpaid. Have the second staff member identify what remains due without taking a real card payment.
- Close the practice party and start a new one at the same table. Confirm that staff can distinguish the new party's records from the earlier records.
Pass criteria: the second staff member can identify both items, their current preparation instructions and their simulated payment states; the change and cancellation have an explicit destination; and the next party is not confused with the first. If a step requires a manual message or a second screen, record the owner of that step and where staff will see it. A successful demonstration of an automatic update should show the resulting status at the receiving end, not merely a button labeled “send.”
A simulation does not prove that the process will hold up during dinner service. After staff practice, run a limited live service pilot with normal guest consent and your usual operational controls. Assign a manager to watch handoffs, check exceptions and pause the workflow if staff cannot tell what has been ordered or paid. Discuss the pilot with the vendor before enabling any live transactions.
Reconcile separate records before closing the table
If the two paths remain separate, make reconciliation a named step rather than an informal reminder. The server responsible for the table can own it; during a shift change, the outgoing and incoming servers should review it together. Choose a backup owner for breaks and busy periods.
Before presenting a bill or closing either record, the owner should:
- Match both records to the current party, using the table identifier and the restaurant's session or turnover procedure.
- Read the items on each record. Check whether similar entries are genuine repeat orders or an accidental duplicate; ask the guest or preparation staff when the records do not settle it.
- Check changes and cancellations against what the kitchen or bar actually received. Give a direct instruction when a correction has not reached the preparation team.
- Compare payment states. A paid QR item should not be requested again on a staff bill; an unpaid staff-entered item should not disappear merely because the QR record is closed.
- Resolve exceptions before closing, and note any unresolved issue for the manager using the restaurant's normal procedure.
For the example table, the owner would find the iced tea on the staff record and the sandwich on the QR record, then check each item's preparation and payment status. If the sandwich appears twice, the owner should investigate before sending or removing anything. Two identical entries could represent two intended sandwiches, not necessarily an error.
Review the workload as well as the feature list. If a separate-ticket process requires two screen checks, a kitchen conversation and a manual correction for routine orders, it may be a poor fit for a busy section. If those exceptions are rare and staff can reconcile quickly, it may be workable. Ask for a written quote that identifies setup, equipment, support and processing costs applicable to the workflow, plus any charges for changes or integrations. Compare the full operating quote, not just a processing fee.
Before deciding, use the guide to fitting QR ordering into table service to define which tasks stay with staff. Then compare your QR requirements with Fleksa's available workflows and ask for a demonstration of the acceptance check above.
Frequently asked questions
Can a server add an item after a guest orders by QR?
That depends on the system and its setup. Ask the vendor to show where the staff-added item appears, how it reaches preparation and whether it shares a bill or requires a separate reconciliation step.
How can staff avoid charging a guest twice?
Check item-level payment status across both ordering paths before presenting or closing a bill. If records are separate, assign one person to match them to the current party and resolve any unclear payment state.
Is a QR menu enough for mixed ordering?
Not necessarily. A QR menu may only display items. If guests need to order or pay from their phones, confirm those functions and test how their orders reach staff and preparation alongside server-entered items.
