Keep the greeting, sensitive questions, food delivery, problem resolution, and a final check under staff ownership. Guests can often handle straightforward ordering, reordering, and payment by phone, provided someone is responsible for watching the table and helping when the process stalls.
The right split depends on your menu and service style. A quick lunch counter with table delivery may put more steps in guests’ hands than a dining room where recommendations and pacing are part of the experience. In either case, a QR code is an entry point, not a service plan.
Map the meal before choosing the technology
Start with a normal visit, from the moment a party arrives until the table is ready for the next guests. For every step, name the person who owns the outcome, even when the guest performs the action. “The guest orders on their phone” does not answer who notices when they cannot complete the order.
At the greeting, a host or server should explain the choices in one sentence: guests can use the code or ask a staff member to take the order. Point out where to find help. Do not make the phone the only way to begin a meal.
Next come menu questions and recommendations. A guest may be happy to browse independently, but a server should remain available for questions about ingredients, preparation, substitutions, or what to order. For an allergy or other serious dietary concern, have staff follow the restaurant’s established process for checking with the kitchen. A menu note alone should not substitute for that conversation.
Order submission is a separate decision from recommending food. In a staff-led flow, the server takes the order and enters it. In a guest-led flow, the guest submits it, and the restaurant needs a clear way to associate it with the right table. Decide how staff will recognize a submitted order and what happens if a guest says they ordered but the team cannot find it.
Delivery remains a staff responsibility in a table-service restaurant. The runner needs the right destination and enough information to resolve uncertainty without guessing which party ordered a dish. A server should also check back at a suitable point: a guest who can place an order by phone may still need a missing utensil, a correction, or a refill.
Finally, decide how payment and departure work. If guests can pay by phone, staff still need a way to establish payment status before closing out the table. If guests cannot or prefer not to pay that way, tell them how to ask for the check. Avoid treating a scanned code as proof that an order was submitted or a bill was paid.
Use a worksheet to assign each step
The following example is hypothetical. It describes one restaurant’s choices, not a product configuration or a measured result. The room has 12 physical tables, each seating one guest party at a time. During lunch, two servers share the room, with one runner available. The kitchen can handle the restaurant’s normal lunch volume; the exercise does not assume extra kitchen capacity.
The owner expects many repeat guests to order familiar lunch items, but the menu also includes dishes that prompt ingredient questions. The worksheet assigns a primary action and a staff backstop. It does not assume that every guest has a phone or wants to use it.
| Meal step | Primary action | Staff owner and backstop |
|---|---|---|
| Welcome | Host seats the party and explains both ordering paths. | Host alerts the assigned server if the party wants staff-led service. |
| Questions and recommendations | Guest browses; server answers questions. | Server checks serious dietary questions with the kitchen using the restaurant’s process. |
| First order | Guest submits familiar items by phone, or server takes the order. | Server follows up if the party cannot order or is unsure it went through. |
| Food delivery | Runner brings food to the identified table. | Runner confirms uncertain destinations with the server before delivery. |
| Follow-up and additions | Server checks the table; guest may place a simple additional order. | Server handles corrections and checks unresolved requests. |
| Payment and closeout | Guest pays by phone or requests staff help. | Server confirms payment status through the restaurant’s process and closes the table. |
Now change one input. Suppose the same room switches to a dinner menu with more preparation choices and guests who expect recommendations. Keep the 12 physical tables and one-party-per-table limit, but make the first order staff-led. The server can discuss choices, confirm special requests, and enter the order. Guests can still use a phone for a straightforward later addition if the restaurant’s chosen workflow supports it. The runner and server retain the same delivery and follow-up duties.
That change is about the complexity of the first conversation, not the number of tables. A party of two and a party of six each occupy one physical table in this example, but the larger party may need more time and more coordination. If the actual room combines tables for larger parties, map that arrangement separately and confirm how the ordering system identifies the combined seating.
Use the same worksheet for your own service. List the steps, choose the primary action, and name a person or role for the backstop. Then ask whether that role can realistically see and act on the request during a rush. Assigning a server to ten tasks is not useful if nobody has time to notice an unattended table.
Design handoffs that do not leave guests waiting
The most important handoff occurs when a guest needs a person. Make the route obvious without requiring the guest to troubleshoot. A server might explain that guests can ask any floor staff member for help, while the team agrees internally who owns the table afterward. If the software offers a staff-help function, ask how the request reaches the floor and how it is acknowledged. Do not assume that a button alone creates a response.
Give staff a defined response for these situations:
- The guest cannot or does not want to use a phone. Offer a readable menu and a staff-led order and payment path.
- The menu or order is unclear. Have the server answer questions and confirm requested changes before the order goes to the kitchen.
- The guest is unsure whether an order went through. Check the order record before submitting another one. If no order is found, take it through the agreed fallback.
- The food needs correction. A staff member takes ownership, checks with the kitchen, and tells the guest what will happen next.
- The guest needs a check or has a payment question. A server checks the bill and payment status rather than asking the guest to repeat a payment.
Table identity deserves special attention. Ask vendors how a code is associated with a table, what staff see when an order arrives, and how the team handles a guest who scans the wrong code. Also ask how moved parties and combined tables are handled. If the answer requires a manual correction, decide who makes it and how the kitchen is told.
Review the handoff between the ordering screen, your restaurant POS system, and the kitchen. Ask what information arrives at each point, including modifiers, table identification, and order status. If you use a kitchen display system, include the cook or expediter in that discussion. The important question is whether the team can act on an order accurately, not simply whether two products can be connected.
Compare the service choice and the operating cost
A staff-led first order gives a server a natural moment to explain the menu and catch confusion. It also requires staff time at the table. Guest-led ordering can let a party browse and submit when ready, but it shifts some effort to guests and makes clear order confirmation more important. Neither approach removes the need for floor coverage.
Look at the full quote alongside the workflow. Separate software charges from payment processing and any equipment or setup charges. Payment fees are costs; sales are revenue. A deposit, if a vendor requests one, is a payment toward an agreed charge or other contract obligation, not a measure of either sales or processing fees. Ask the vendor to explain when it is due and how it appears in the quote.
Fleksa lets guests scan, order, and pay at the table in a browser without downloading an app. There is no Fleksa commission on table QR orders; payment processing and applicable tax still apply. Check Fleksa plans for current pricing; the plans reference was checked in November 2026. Confirm the quote and the particular table-service setup before deciding.
Do not count a potential labor saving as a guaranteed result. If staff spend less time entering routine orders but more time helping guests or correcting table assignments, the service effect may be small or may differ by shift. For a broader comparison of costs and guest experience, use the related buying guide.
Pilot the handoffs before changing the whole room
First, walk the team through a simulated service. Use a practice environment or a vendor-supported demonstration that cannot create a real payment, send a guest message, or dispatch a courier. If the system cannot safely simulate a step, talk through it with screen examples rather than completing a live transaction. Include a server, runner, and kitchen representative.
Practice a straightforward order, a question that requires the kitchen, a wrong-table scan, an uncertain submission, and a payment-status question. For each one, ask who notices the issue, who acts, and what the guest hears. Check that the fallback is understandable to a new staff member. Revise the worksheet when ownership is unclear.
Only after that rehearsal, consider a limited live service pilot with actual guests. Choose a manageable shift and a defined area, while keeping the normal staff-led path available. Brief the team on which tables are included and who handles issues. A live pilot involves real service, so use your ordinary controls for orders and payments rather than treating guests’ transactions as practice.
Observe whether greetings happen promptly, how often guests need help, whether orders reach the right table, and whether the kitchen receives enough detail. Note the time or service point at which a problem occurs, not just the total number of problems. Ask guests a short, optional question such as, “Was it clear how to get help?” Invite staff and kitchen feedback after the shift as well.
Agree on stop conditions before service. For example, return a table to staff-led ordering if the team cannot reliably identify its order, if a guest cannot complete the process, or if kitchen instructions are unclear. Afterward, decide whether to keep the split, change specific handoffs, or stay staff-led. A small pilot should produce a decision, not pressure the team to expand.
Ready to map your own service? Take the worksheet to your next pre-shift meeting, assign an owner to every backstop, and compare those requirements with Fleksa QR ordering.
Frequently asked questions
Should guests place their first order by phone?
They can when the menu and service style make that comfortable. Keep the first order staff-led when guests need detailed recommendations, complex changes, or a conversation with the kitchen.
What if a guest cannot scan the code?
Offer a menu and let a staff member take the order and arrange payment. Explain that alternative at the greeting so the guest does not have to struggle first.
Does a QR menu include ordering and payment?
Not necessarily. Ask whether guests can only view the menu or can also submit an order and pay, and check how staff see the order and payment status.
