For a shared counter, identify each physical seat separately if the ordering system can carry that seat identifier through to the staff who deliver the food. If it cannot, use a staffed handoff: the counter identifies the general location, and an employee confirms the guest before delivery. Choose only after demonstrating what happens when someone moves.
A counter is one physical service area, not necessarily one dining party. Two friends may sit next to each other, while the guest beside them orders alone. The useful question is whether an order can be connected to the right person without staff guessing from a shared counter label.
Start with the physical seats
Walk the counter and count usable seats, including any that are temporarily unavailable. Give each position a visible identifier that staff can read from their normal approach. A simple sequence is easier to explain than a mix of numbers and nicknames.
Hypothetical layout: Counter seats C1 | C2 | C3 | C4 | C5 | C6
For this example, assume there is one shared physical counter with six usable seats and no separate physical tables. Its capacity is six seated guests, not six parties. A party can occupy more than one seat. The labels C1 through C6 identify positions, not people or checks.
The input for the map is the operator's count of usable seats and the position of each label. During setup, confirm that count in the room. Then ask the vendor to show how a scan at each position appears in the order workflow. Do not assume a QR code that opens a menu also creates an order or accepts payment.
Place each code where the intended guest can reasonably reach it, without making it easy to scan the neighboring seat by mistake. Check what happens when menus, condiments or bags cover a label. If stools move freely, decide whether the code belongs on a fixed counter position rather than the movable stool.
Also decide how a guest orders without a phone or when a code cannot be scanned. A staff-entered order or another existing service method may be appropriate, but it still needs a location that the runner can understand.
Compare seat mapping with staffed handoff
Suppose two friends sit at C2 and C3. Each scans the code at their own position and orders a drink. A third guest sits at C4. The restaurant wants to serve all three accurately without treating them as one party merely because they share a counter.
The worksheet below compares two possible workflows for that same six-seat layout. These are design outcomes to demonstrate, not claims about a particular product.
| Decision point | Seat-level mapping | Staffed handoff |
|---|---|---|
| Location on an order | C2 or C3 follows the relevant order to staff. | The order identifies the shared counter; staff confirm the guest. |
| Two friends ordering | Each order has its own seat reference, even if the guests are together. | A staff member matches each drink to its guest before serving. |
| Guest moves | Staff update or otherwise clearly communicate the new location before delivery. | The assigned employee finds and confirms the guest at the new location. |
| Best fit | The identifier remains accurate and visible throughout the workflow. | Seat identity cannot reliably follow the order, but staff can manage the confirmation step. |
The choice turns on what reaches the person serving the order. If C2 appears only on the guest's screen but the runner sees “counter,” the operation still needs a staffed handoff. If C2 appears on the relevant staff view and can be corrected after a move, seat-level mapping may reduce the need to ask where every order belongs.
Ask separately how the system handles a shared party and payment. Two seat identifiers do not necessarily mean two checks, and one party does not necessarily mean one payment. Have the vendor show the intended workflow for guests who order separately and for guests who want to pay together. If that workflow does not suit the restaurant, keep the seat identifier for delivery and use an agreed staff process for the check.
Compare this decision with the wider service flow in the guide to choosing where QR ordering fits. The aim is not to label every possible surface; it is to give staff enough reliable information to serve the right guest.
Test a seat change before service
Use a simulation with staff acting as guests. Do not take a real card payment, send a real guest message or dispatch a courier. Ask the vendor how to keep the demonstration isolated from live orders, payment processing and notifications before starting.
Start with the simulated guest at C2. Have them scan and place a simulated order, then move to the empty C5 position before delivery. Assign the counter attendant to notice the move and tell the runner. The runner should not deliver based on the original C2 label until the new location is confirmed.
For seat-level mapping, ask the vendor to demonstrate how staff correct the location or communicate the change within the actual service workflow. The runner must see a clear, current instruction to deliver to C5. An unchanged C2 label, accompanied only by the assumption that the runner will somehow know, fails this test.
For staffed handoff, the attendant can take responsibility for finding the guest and identifying the order to the runner. In the simulation, the handoff passes if the runner confirms the intended guest at C5 before serving. If nobody owns that confirmation, a shared “counter” label does not provide a dependable fallback.
Run one more simulated check with adjacent seats: have the C3 guest scan the C2 code by mistake. Ask how the error is noticed and corrected before the order is delivered. Clear labels help prevent this, but the restaurant also needs a recovery process when a guest scans the wrong code or changes places.
After the isolated demonstration, a live service pilot is a separate decision. If you run one, brief the team, assign an exception owner and use the restaurant's normal approved procedures for actual orders and payments. Start within a service area the team can monitor, and stop the pilot if staff cannot reliably match orders to guests.
Set acceptance criteria and assign an owner
Before a vendor demonstration, write down the route an order must take: guest scan, order details, payment status where relevant, staff view and delivery. Ask to see the same route for a guest without a phone. A restaurant POS system may be part of that route; confirm exactly which screen or printed instruction the runner will use rather than relying on a setup diagram.
Use these pass conditions for the simulated demonstration:
- Identification: A scan at C2 produces the intended location in the staff workflow, or the vendor shows a workable shared-counter handoff.
- Adjacent guests: Staff can distinguish the simulated C2 and C3 orders without assuming the guests are one party or one check.
- Move: The counter attendant detects the move, and the runner receives or confirms the corrected C5 destination before simulated delivery.
- Wrong scan: Staff can identify and correct a mismatch between the scanned position and the guest's actual position.
- Payment and fallback: Staff can tell the simulated payment status using the demonstrated workflow and can handle a guest who does not scan.
Record a pass only when the staff member responsible for the next action can see or receive the information needed to perform it. If the move cannot be reflected reliably, seat-level mapping fails that criterion even if the original scan worked. Staffed handoff is acceptable only if an employee is assigned to confirm the guest and can realistically do so during service.
Make the shift manager the owner of unresolved location exceptions. The manager should decide who finds the guest, who updates the order if that is possible, and when a runner must pause delivery. Include this in the opening and shift-change briefing so an unresolved order does not lose its owner.
Fleksa's QR ordering lets guests scan, order and pay at the table in a browser without downloading an app. Ask whether the specific counter-seat identification, move and handoff workflow you need is supported in your setup. Review current plan details at Fleksa plans and request a quote; pricing details were checked in November 2026. Compare processing and other applicable costs separately from the plan price.
Next step: Take your counter map and the five pass conditions to a Fleksa QR ordering demonstration. Compare the requirements with the available setup, and confirm current support before choosing a workflow.
Frequently asked questions
Should every counter seat have its own QR code?
Use a separate code for each position when the resulting identifier reaches staff and remains usable after a move. If that cannot be demonstrated, a shared-counter code with a clearly owned staff confirmation may be more reliable.
Can two guests sitting together order separately?
They may need separate seat references for delivery even though they are one party. Ask the vendor to demonstrate separate orders and the payment arrangement the guests want; do not assume either follows from the seat labels.
What if a guest moves after ordering?
The counter attendant should notice or be told about the move and make sure the runner has the current location. Test the correction process before service; if it does not work, use an assigned staff handoff rather than relying on the old seat label.
