One service team can handle QR orders from separate dining rooms with repeated table numbers if each order carries a clear room-and-table identity through the whole service workflow. The important test is not whether the guest can scan a code. It is whether the person accepting, preparing, and delivering the order can distinguish Main Room table 4 from Garden Room table 4 without guessing.
Ask a vendor to demonstrate that distinction on the screens and tickets your team would actually use. Then test what happens when the location is missing or a guest scans the wrong code. A room label that appears only during setup is not enough for a runner at the pass.
Start with a room-and-table map
Make a list of the physical tables where guests might scan. Use the names your team says during service, and pair each name with a table number. A physical table is a location; a guest party is the group sitting there. The same table may serve several parties over an evening, and one party may move between tables. Neither fact should change what the printed QR code identifies.
Hypothetical example: A restaurant has a Main Room and a Garden Room, each with tables numbered 1 through 6. There are 12 physical tables in total, with capacity for one party at each table at a time. One shared service team takes orders to both rooms. The manager supplies the room names and table numbers from the floor plan; the vendor demonstrates how those locations are configured and displayed. The example assumes separate codes can be assigned to each physical table, subject to the demonstration.
| Physical location | Code label to check | Information needed at handoff | Action if unclear |
|---|---|---|---|
| Main Room, table 4 | Main Room 4 | Room and table on the order view used by the runner | Hold and ask the shift lead to verify |
| Garden Room, table 4 | Garden Room 4 | Room and table on the order view used by the runner | Hold and ask the shift lead to verify |
| Main Room, table 6 | Main Room 6 | Room and table on the order view used by the runner | Hold and ask the shift lead to verify |
This worksheet is a starting map, not proof of what a product displays. Add every physical table before setup, including temporary locations if you plan to use them. Walk the floor with the person who will place the codes. Compare each printed label with its intended location, and agree on room names that are easy to read and say aloud.
Separate what you can observe from what you are assuming. A visible order labeled “Main Room 4” is an observation. Assuming that the same label appears on a kitchen ticket, a payment view, or a runner screen is not. Ask to see each view your proposed workflow depends on. If the team uses a restaurant POS system, include that view in the demonstration rather than treating the QR screen as the entire workflow.
Trace two table 4 orders at the same time
Continue the hypothetical example with two simultaneous practice orders. The party at Main Room 4 orders soup; the party at Garden Room 4 orders a sandwich. These are two orders from two physical tables, not two orders from one table or a count of the guests at either table.
Ask the vendor to show both orders as they move from the scan through acceptance and preparation to the runner handoff. Have a staff member who did not set up the codes read the destinations. That check is more useful than asking the person who configured the system to explain where each order belongs.
Outcome A: both locations stay distinct
The order views used by the team show “Main Room 4” next to the soup and “Garden Room 4” next to the sandwich. The runner can identify both destinations without opening an unrelated setup page or asking the person who configured the codes. If the restaurant's other requirements are also met, this supports using the shared team with the proposed room names.
Outcome B: the room disappears
Suppose the runner's view shows “Table 4” for both orders. Even if an earlier screen showed the rooms, the final handoff is ambiguous. Do not accept a demonstration that relies on the runner remembering which order came first or recognizing the items. Ask whether the runner's view can show the full location, whether another view can be used at the pass, or whether a different table-naming scheme can carry the distinction throughout.
A workable alternative might be a unique table name for every physical location, such as “M4” and “G4,” if the system displays those names wherever staff need them and the team understands the abbreviations. Demonstrate that alternative rather than assuming it works. If neither full room labels nor an agreed unique naming scheme reaches the handoff, the setup fails this restaurant's central requirement.
Also ask what the order shows when a guest moves after scanning. Does the original location remain attached? Who can change it, and where does that change appear? The answer determines whether staff need a manual relocation step before preparing or delivering the order. For a broader decision about when guests should order themselves and when staff should help, see the table-service buying guide.
Test wrong codes and unclear assignments
Clear labels do not prevent every mistake. A code can be placed on the wrong table, a guest can scan a neighboring table's code, or a party can move. Decide in advance who catches the problem and who has authority to resolve it.
For this example, make the shift lead the exception owner. The lead compares the order location with the floor map and, when necessary, asks the server to confirm the party's location. The runner holds an ambiguous order instead of choosing a room. The lead then uses the demonstrated correction process or gives the runner a verified destination through the restaurant's agreed handoff. Ask the vendor whether a correction is reflected on every staff view the team uses; if not, define how staff will avoid acting on an old label.
Run two separate failure checks. First, place the practice code labeled Main Room 4 at the simulated Garden Room 4 location. The order may accurately reflect the code while pointing to the wrong physical table. A manager should catch that mismatch during the floor-map check; a clear software label alone would not catch a misplaced sticker.
Second, create a practice order with an intentionally unclear destination, or ask the vendor to demonstrate how staff handle one if the system does not allow a blank location. The runner should stop and escalate it. A pass requires a verified destination before the handoff; a plausible guess is a failure. The shift lead should record the cause and restore the correct practice setup before repeating the test.
Check assignment controls as well. Ask who can create or rename a location, replace a code, or correct an order after a move. If multiple staff members can make changes, agree on who checks them against the floor map. Include an approach for guests who cannot or do not want to use a phone, so staff can still take an order and identify the right table.
Set a pass-or-fail demonstration
Use the same people and handoff points you expect during service: the shift lead, the person accepting or preparing orders, and a runner. Before starting, agree with the vendor on a simulation or test environment. Practice must not create a real card payment, send a guest message, or dispatch a courier. Ask the vendor to show payment status using test data, without running a real transaction.
- Map: The manager identifies each practice code's intended physical table. Another staff member checks the code labels against the floor map.
- Submit: Create the two simultaneous table 4 practice orders. Note which room and items belong to each order before showing them to the runner.
- Follow: Inspect the room-and-table identity at acceptance, preparation, and the runner handoff. Check the views or tickets the restaurant actually intends to use.
- Hand off: Have the runner state both destinations without help from the code configurator. Check the answers against the original practice record.
- Escalate: Introduce a misplaced code and an unclear destination as separate checks. The runner holds the unclear order; the shift lead verifies and resolves it using the agreed process.
- Move: Demonstrate how staff handle a party that changes tables, including how the runner learns the verified new destination.
Pass: Both simultaneous orders remain distinguishable at every required handoff, the runner names both destinations correctly, and the shift lead resolves the exception before delivery. Fail: Any required handoff shows an ambiguous destination without a demonstrated, reliable way to resolve it, or the runner is expected to guess. Record the exact screen or step that failed and repeat the full check after any proposed change.
This is a simulated check, not a live service pilot. If it passes and you want a live pilot, agree on the participating tables, staff responsibilities, escalation method, and stop conditions first. A shift lead should monitor real orders during that separate pilot and pause the workflow if staff cannot identify a destination. Compare the setup with the rest of your restaurant management software workflow, including who sees payment status and where staff make corrections.
For your next step, bring your floor map and this checklist to a vendor demonstration. Compare your QR requirements with Fleksa and confirm current support for room labels, assignment changes, and runner handoffs before choosing a workflow.
Frequently asked questions
Can both rooms use table 4?
They can on your floor plan, but the order workflow must distinguish the two physical locations wherever staff need that information. Test full room labels or another unique naming scheme through the runner handoff.
Does a QR menu identify and route orders?
Not necessarily. A QR menu alone is not automatically ordering or payment software. Ask the vendor to demonstrate how a scan becomes an order and how its location reaches the staff who serve it.
What should a runner do if an order only says table 4?
Hold the order and ask the designated shift lead to verify the destination. Do not infer the room from the food, the order sequence, or memory.
