When a guest cannot scan a QR code or simply does not want to order by phone, a staff member should offer a printed menu, take the order and remain responsible for getting it to the kitchen and confirming how the guest will pay. The guest should not have to explain their reason or find another device.
Make that alternative part of the service plan, not an exception staff have to improvise. Decide who takes the order, which menu has current prices and availability, and how the order reaches the same preparation and payment workflow as other table orders. Then practice the handoff before a busy shift.
Identify the barriers without making guests troubleshoot
A guest may have no phone, a dead battery, a damaged camera or a device that cannot read the code. A connection may fail, a page may not load, or the screen may be difficult for the guest to use. Someone may also prefer to talk to a server or avoid entering payment details on a phone.
These situations call for the same first response: offer a staffed route. A simple prompt at seating can help: “You can order with the code or ask us for a menu.” Put the same choice on a small sign or menu holder if that fits your dining room. Keep printed menus where staff can reach them quickly rather than making a guest wait while someone searches a storage area.
If a guest wants help with the code, a staff member can offer basic assistance. Do not make repeated scanning attempts a condition of getting service. Staff should not take a guest’s phone out of their hands, ask for a password or enter card details for them. Move to the staffed option when the guest prefers it or the problem is not quickly resolved.
Separate a guest’s device problem from a wider service problem. If one phone cannot connect, the staffed route may work normally. If the restaurant’s ordering connection or equipment is also unavailable, staff need a documented way to record orders and communicate with the kitchen. Ask your software provider what remains usable during a connection failure; do not assume that orders or payments can be processed offline.
Choose the staffed route before the rush
A printed menu solves the reading problem, but it does not take an order by itself. Pair it with a named staff member who can answer questions, record choices and send the order onward. A staff-assisted route can use a normal server workflow, provided the order is entered or communicated through a method your restaurant has agreed on.
Fleksa’s QR ordering lets guests scan, order and pay at the table in a browser without downloading an app. For guests who do not use that route, ask how a staff-entered order would reach your configured restaurant POS system and, if used, the kitchen display system. Confirm the actual steps in your setup rather than assuming every route shares the same handoff.
Use this hypothetical worksheet to assign a route and owner. It assumes a dining room with 12 physical tables, each seating at most one guest party at a time, and two servers. During the period considered, one server can manage up to three parties needing full staff order-taking while the other covers the remaining service. That is a planning assumption, not a universal staffing standard.
| Guest situation | Route | Owner and action | Capacity decision |
|---|---|---|---|
| One party has no usable phone | Printed menu and staff order-taking | Assigned server takes and sends the order | One of three assisted-party slots is used |
| Three parties prefer staff service | Printed menus and staff order-taking | Assigned server handles all three parties | All three assisted-party slots are used |
| A fourth party also requests staff service | Printed menu; another staff member takes the order if available | Shift lead assigns an owner and gives the party an honest wait estimate | Do not assign a fourth party to the first server under this plan |
| Restaurant connection is unavailable | Use the documented connection-failure procedure | Shift lead confirms how orders reach the kitchen and how payment can be handled | Accept only the service volume the team can reliably handle |
The table shows why a fallback needs both a route and a limit. The first three parties fit the assumed assisted-service capacity; the fourth needs another available person or a wait. The number of occupied tables alone does not tell you whether staff can respond promptly. For your own worksheet, replace those assumptions with the number of parties your team can actually support and decide who can help when that limit is reached.
If you use handwritten tickets during a broader outage, agree on who carries each ticket, where completed tickets go and who checks for missed items. Keep the paper route short enough to follow under pressure. If the team cannot communicate an order or determine a workable payment method, say so before accepting it.
Keep the menu, table and payment handoff clear
Printed menus are only useful if they reflect what the kitchen can serve. Assign one person on each shift to confirm price changes and unavailable items before service. Remove outdated copies and give servers a concise list of changes. When an item sells out during service, tell the person taking assisted orders as well as anyone managing the digital menu.
For frequent changes, consider a dated insert or a short availability sheet alongside the printed menu. The guest should hear the current price and any relevant substitution before the order is sent. If staff discover a discrepancy afterward, return to the table and confirm the guest’s choice rather than silently changing it.
Identify the physical table using the restaurant’s established table number or another agreed identifier. Repeat that identifier when passing the order to the kitchen or entering it into the ordering system. If guests move before ordering is complete, update the person responsible for the handoff. This is about keeping a staffed order attached to the right party; it is separate from configuring the QR codes themselves.
Payment needs its own check. An order taken by staff should not be treated as paid merely because it is recorded. Ask the guest how they intend to pay using the methods the restaurant currently accepts, and make sure the person closing the check can see or verify its status. If a guest begins an order on a phone and then asks for help, first check whether it was submitted or paid. That reduces the risk of entering the same order twice or asking for payment twice.
Assign ownership until the handoff is complete. “I’ll take care of your order” should mean the staff member either follows it through or tells a named colleague what remains to be done. A shift lead can help when responsibility is unclear, but the guest should not have to repeat the whole order to several people.
Practice the handoff and measure unresolved requests
Walk through one assisted order with the team before relying on the plan. Use a simulation: a staff member plays a guest whose phone cannot scan, receives a sample printed menu and asks to order. The assigned server records the choices, repeats the table identifier and explains the intended kitchen and payment handoff. Stop short of submitting a real order, charging a card, sending a guest message or dispatching a courier.
At the end of the simulation, ask the person playing the guest who owns the next step. Ask the server where they would check availability and payment status. If the answer depends on another employee, have the server name that employee and describe what information they would pass along. Correct an unclear handoff before practicing again.
A live service pilot is different. Use the normal service workflow with consenting staff and real guests who choose it; handle any actual order and payment through the restaurant’s ordinary procedures. Start at a manageable service period, watch for delays and have the shift lead available to resolve problems. Do not present a simulation as proof of live performance.
Track a few operational signals on a simple shift sheet: how many parties requested staff help, how many were still waiting for an owner after the request, and what stopped an unresolved request from moving forward. Record the reason in practical terms, such as no menu available, an availability question or an unclear payment status. Avoid collecting unnecessary details about the guest or their device.
Review unresolved requests at the shift handoff. If menus are hard to find, change where they are kept. If the same server repeatedly reaches the assisted-party limit, assign backup earlier or reduce the service volume the team accepts. If payment status is unclear, revise the check before staff create a second order. The measure is not how often guests choose a phone; it is whether every guest has a workable route and a person responsible for it.
Before your next service, write down the fallback owner, menu location, order handoff and capacity limit. Then compare that workflow with Fleksa QR ordering and ask how your intended staff-entry and payment steps would work in your setup.
Frequently asked questions
What if a guest does not want to scan the QR code?
Offer a printed menu and have an assigned staff member take the order. The guest does not need to give a reason for choosing staff service.
Can a printed menu be the entire fallback?
No. Staff still need a way to confirm current availability and prices, send the order to the kitchen, identify the table and check payment status.
What should staff do if both the guest’s phone and the restaurant connection fail?
Follow the restaurant’s connection-failure procedure and confirm how the order can reach the kitchen and how payment can be handled before accepting it. Do not assume offline ordering or payment is available.
