To keep guests from ordering items unavailable in their seating area, first define what each area can serve. Then check that each QR code opens the appropriate menu and that an unavailable item cannot reach staff as an accepted order. If your system cannot enforce that rule, use a restricted menu or a staff-assisted ordering process for the affected area.
The distinction matters because a QR menu may only display food and drinks. A QR ordering system also accepts selections, and some systems take payment. An accurate display is useful, but the buying decision depends on what happens when a guest tries to place an order.
Map each item to the areas that can serve it
Start with the actual service areas, not just the names on your floor plan. A bar, dining room, and terrace might have different equipment, staff coverage, or rules for carrying food and drinks. An item can be prepared in the same kitchen and still be impractical to serve everywhere.
For the following hypothetical example, assume a restaurant has three areas. The bar can serve drinks and cold food. The dining room can serve the full menu. The terrace can serve drinks and cold food, but staff cannot carry hot dishes there during the current service setup.
| Item | Bar | Dining room | Terrace |
|---|---|---|---|
| House lemonade | Available | Available | Available |
| Cold mezze plate | Available | Available | Available |
| Hot skillet | Unavailable | Available | Unavailable |
The table is an operating rule, not a description of what any particular software can enforce. For this restaurant, the hot skillet should not be orderable from a bar or terrace code. If the software cannot reliably make that distinction, the owner should keep the skillet off those QR menus or take orders with staff in those areas.
Build your own list from items most likely to cause trouble: dishes requiring special equipment, drinks served only where a bartender is working, or items restricted during a particular shift. Note whether a restriction applies all day or only at certain times. A terrace rule for lunch may not fit an evening service with different staffing.
Separate area restrictions from sold-out items. If the kitchen runs out of the mezze plate, it should be unavailable everywhere, not merely hidden on one area menu. Ask how a sold-out change interacts with area menus and whether staff must update each one separately.
Compare what each code shows and accepts
Before printing codes or opening a new section, make a list of the codes and the physical tables or locations they represent. A code at a bar seat and a code on a dining-room table may look identical to a guest, but they need the correct location behind them. Check the assignment whenever tables move or codes are replaced.
Use a safe simulation or vendor-provided test environment. Scan a representative code from each area with a phone, then compare what appears with your availability map. For the hypothetical restaurant, look for the lemonade and mezze plate in all three areas. The skillet should be available in the dining room and absent or clearly unavailable in the bar and terrace.
Showing the right menu is only the first check. Ask the vendor to demonstrate whether the system blocks an unavailable selection when a guest has an older menu open, follows a saved link, or starts an order before an area rule changes. Also ask what happens when a guest moves from the dining room to the terrace after scanning. A location tied to the original code may need a fresh scan or staff intervention.
Keep the exercise simulated: do not make a real payment, send a guest message, or trigger a courier dispatch. If a safe test environment is not available, ask for a walkthrough that does not submit a live order. A later live-service pilot is different: staff handle real guests under normal service procedures, with a manager watching for problems and a fallback ready.
Use the table QR codes guide to prepare questions about code placement and table identity. For the broader service decision, the guide to where QR ordering fits in table service can help you decide which areas should use it at all.
Trace an unavailable item through the handoff
Walk through the full path, rather than stopping when the menu looks right. In the hypothetical restaurant, a terrace guest wants the hot skillet. The desired result is that the terrace code does not let the guest submit that item for the terrace. The guest can choose an available dish or ask a staff member for help.
Ask the vendor to demonstrate each step in a simulation:
- Selection: Is the skillet hidden, marked unavailable, or visible until the guest tries to add it? Is the message clear enough for a guest to understand?
- Cart and submission: If the guest already has the item in a cart when the rule changes, is it removed or blocked before the order is accepted?
- Payment: If the workflow includes payment, when is the final availability check made? What can staff do if an item cannot be fulfilled after an order has been accepted?
- Staff handoff: What location and order details do staff see? If an exception reaches them, who contacts the table and offers an alternative?
Do not assume that hiding an item is the same as blocking an order through every route. Ask whether area rules apply to the menu, cart, and order submission, and whether they also apply when staff enter an order. Those may be different workflows.
Agree on the staff response before service. A server who sees a terrace order for the skillet should know whether to speak with the guest, suggest an available item, and involve the manager. If payment has already occurred, the manager also needs to know the system's correction or refund process. The exact steps depend on the payment and ordering setup, so get a demonstration rather than relying on a generic promise.
For guests who cannot or prefer not to scan, provide a current printed menu or staff assistance. That fallback needs the same area restrictions. Otherwise, a careful QR setup can still leave staff offering an item they cannot deliver.
Assign updates, checks, and a fallback
Choose one role to own the availability map and another to verify changes before the affected service. In a small restaurant, the manager may own the rules while a shift lead checks the codes. Write down who can make changes when the manager is away, and where staff can find the current area list.
Use a short change routine. When an area opens, closes, or changes its service model, the person making the change records the affected items and codes. The verifier then scans or simulates the relevant locations, checks at least one allowed item and one restricted item, and tells the team when the update is ready. If a change cannot be verified safely before service, use the fallback rather than guessing.
That fallback might be a simpler area menu with only items the team can consistently serve, or staff-assisted ordering until the configuration is corrected. Tell the team where the fallback applies and remove or cover codes that would direct guests to the wrong workflow. Restore them only after the location and menu have been checked.
During a live-service pilot, watch for wrong-location orders, guest questions, and corrections staff have to make. Record what happened and which code was involved; do not treat a quiet shift as proof that every edge case is covered. Recheck after menu edits, table moves, staff coverage changes, or a new terrace schedule.
Before choosing software, bring your area map and one difficult item to a vendor demonstration. Ask the team to show the guest view, the attempted order, and the staff handoff for each area. Compare the QR ordering workflow and current availability with Fleksa; its table QR ordering lets guests scan, order, and pay in a browser without downloading an app. Ask specifically how your area restrictions would be configured and maintained.
Frequently asked questions
Is a different QR code for each area enough?
Not by itself. Confirm that each code points to the right location and menu, and that unavailable items cannot be submitted through that area's ordering workflow.
What if an item becomes unavailable during service?
Ask how staff mark it unavailable and whether that change applies across every affected area. Also check what happens to the item in carts that guests already have open.
Can guests order without using a phone?
Plan a staff-assisted option or a current printed menu. Keep its area restrictions aligned with the QR menu so guests receive consistent choices.
