Phone ordering can work in a seating area when guests know what happens after they order and a named person is responsible for the next step. That can be a server delivering to a table or a counter employee calling guests to collect their food. An area with no dedicated server is not automatically unsuitable. An area with no clear monitoring or handoff is.
Start with the service model, not the number of QR codes you can print. Map each physical table or seating zone, identify who watches for orders and decide how guests get help. Then check the workflow before inviting guests to use it.
Map who watches each area and carries orders
Walk through the restaurant as a guest would. Divide seating into areas that have different staff coverage or different ways of getting food. A dining room with assigned servers and a counter-service section may need separate instructions even if they share the same kitchen.
For each area, write down four things: who notices a new order, who prepares or releases it, who gets it to the guest and who handles an exception. Name a role for every shift, rather than relying on whoever happens to be nearby. Also name a backup for breaks and busy periods.
Table identity matters where food is delivered. The order needs enough location information for the runner to find the correct physical table, and staff need a way to resolve a mismatch. If guests collect at the counter, decide how they will recognize that their own order is ready without exposing unnecessary personal information.
The following worksheet uses a hypothetical restaurant. It has eight physical tables in a staffed dining room and six physical tables in a counter-service zone. Each table can seat one guest party at a time. A party might contain one person or several; the table count is not a count of guests or orders.
| Area and capacity | Order monitor | Food handoff and help | Initial decision |
|---|---|---|---|
| Dining room: 8 tables, up to 8 parties | Assigned server; shift lead covers breaks | Runner delivers to the identified table; server handles questions | Candidate for table delivery |
| Counter zone: 6 tables, up to 6 parties | Counter employee; shift lead is backup | Guest collects at counter; counter employee handles questions | Candidate for counter pickup |
| Any area without an assigned monitor | None | No dependable handoff or help | Do not launch there yet |
These are capacity limits for the example, not a prediction that all tables will be occupied. The worksheet makes the decision visible: both named areas could support phone ordering, but only if the relevant staff can monitor the workflow and the guest-facing instructions match it. If the counter employee cannot watch incoming orders during a rush, the counter zone needs a different assignment or should remain outside the launch.
Ask each vendor how an order identifies a table or pickup location, how employees see it and how staff can correct a location error. Also ask what happens if an employee misses an alert. A printed table number alone is not proof that the number reaches the people who need it.
Choose the service model for each zone
In the hypothetical dining room, the guest scans at the table, places an order and expects delivery there. The assigned server remains responsible for the party even when the guest orders by phone. The runner needs to see a usable table identifier, while the server needs to know whether the guest needs help or has already ordered.
A short sign might say: Order and pay on your phone. We will bring your food to this table. Ask your server if you need help. Use that wording only if the actual setup and staffing support each promise. Decide whether staff still check on the table, clear dishes and take additional orders in person. Tell the team so that a guest does not receive different answers from the host and server.
In the counter zone, the same promise would create the wrong expectation. The hypothetical guest orders from a phone but collects food at the counter. A suitable instruction might say: Order on your phone, then collect your food at the counter. Ask our counter team for help. Add the actual method for telling guests their order is ready once you have chosen and verified it.
Counter pickup does not eliminate the need for staff coverage. Someone must watch incoming orders, coordinate with the kitchen and make sure a waiting guest can find the right collection point. If that person also takes walk-up orders, consider what happens when a line forms. A shift lead may need to cover the monitor, or the restaurant may need to pause phone orders in that zone during the busiest period.
Give guests a non-phone option in both areas. That might be ordering with the server or at the counter. Put the alternative near the QR code and make sure staff know how to use it. A guest should not have to explain why they cannot or do not want to scan.
Fleksa's QR ordering lets guests scan, order and pay at the table in a browser without downloading an app. A QR menu alone does not necessarily take orders or payments. Ask whether the setup supports each handoff you plan to offer, including the counter-pickup workflow, before printing instructions. For the wider table-service decision, see this related buying guide.
Check notifications, instructions and exceptions
Run a simulation with employees before a live service pilot. Use a vendor-provided demonstration or safe test mode and confirm its boundaries first. The simulation must not create a real card payment, send a message to a guest or dispatch a courier. Use staff as pretend guests and clearly label the scenarios as practice.
Follow an order from the point where a person sees the sign through to the handoff. Ask the vendor to demonstrate how order details reach the relevant screen or device, how payment status is shown and how staff distinguish one table or pickup order from another. If you use a restaurant POS system, ask how the proposed QR workflow connects to it and what staff will actually see.
Use observable pass or fail checks rather than asking whether the process felt easy:
- Instruction check: A staff member acting as a guest can state whether food comes to the table or must be collected, and can find the non-phone option. Fail if the sign or staff gives the opposite expectation.
- Notification check: The assigned monitor can find the simulated order and identify the next action. Fail if an order is visible only to someone who is not watching that area.
- Location check: For dining-room delivery, the runner can match the simulated order to the correct physical table. Fail if two tables are ambiguous or the location is missing.
- Payment check: Staff can tell the simulated payment status before taking the next action. Fail if they must guess whether payment was completed or retry a real charge to find out.
- Exception check: The team can explain who handles a wrong table, an unavailable item, a guest question and a missed notification. Fail if any case has no owner or fallback.
Record what happened and who needs to change the process. A missed notification might call for a different screen location, a backup check or a narrower launch. A wrong-table scenario might call for clearer table labels or a staff confirmation step. Do not treat a successful demonstration of ordering as proof that every exception is covered.
Ask for the full operating quote as well as the processing rate. Fleksa says it charges no commission on table QR orders; payment processing and applicable tax still apply. Check Fleksa's plans for current pricing, checked in November 2026, and ask for any setup, device or other applicable charges in writing. A processing fee alone is not the all-in cost of running the workflow.
Set a launch boundary and review point
For the hypothetical restaurant, a reasonable first boundary is the eight-table dining room during shifts when an assigned server and backup are both present. That recommendation follows from its stated coverage: the server owns guest questions, the runner delivers, and the lead covers breaks. The six-table counter zone remains a candidate, but waits until the owner confirms that its monitor can cover phone orders alongside the walk-up line.
The launch boundary should include times as well as places. Write down which shifts are included, who can pause phone ordering and what guests should do if it is paused. Remove or cover instructions that no longer match the service being offered. Brief hosts, servers, runners, kitchen staff and counter employees before the first live shift.
After the simulation passes, a live service pilot uses actual guest orders and the restaurant's normal operating procedures. Set a review after the first three eligible shifts, or sooner if a serious handoff problem appears. During those shifts, the lead can record whether each observed order reached the right handoff, whether staff could see payment status and whether guests understood delivery versus pickup. Note missed orders or unclear cases, not just completed ones.
Keep the boundary if the team can account for every observed handoff and has a workable response to each exception. Pause the affected area if an order is not noticed, a payment status cannot be resolved or guests repeatedly wait for delivery in a pickup zone. Fix the cause and repeat the relevant safe simulation before trying that workflow in live service again. Expand only when the next area has its own monitor, backup, instructions and handoff.
Take your completed area map to Fleksa and compare each requirement with the available setup. Confirm current availability, the staff view and the fallback for each seating area before choosing a workflow.
Frequently asked questions
Can an unstaffed seating area use QR ordering?
It can be a candidate if someone elsewhere monitors orders, guests know how to collect food or receive delivery, and a named employee handles problems. Without those assignments, leave the area out of the launch.
Does a QR menu let guests order and pay?
Not necessarily. A code may only open a menu. Ask the vendor to show the ordering, payment-status and staff handoff steps for your intended service model.
What should guests do if they cannot scan?
Offer a clear alternative, such as ordering with a server or at the counter. Put the option near the code and make sure employees know how to help.
