The most useful QR ordering adoption number is the share of eligible guest parties that submit an order through the QR workflow. Pair it with the share that pays through that workflow, the number of menu views, and the value of paid orders. Scans can show interest, but they do not show how many parties ordered or how much you sold.
Choose the unit before you calculate anything. A physical table can serve several parties during a shift, and one party can use several phones. For most table-service decisions, an eligible guest party is a more useful starting point than a table, a device, or a scan.
Define the funnel before counting
Start with the service period and the area where QR ordering is actually offered. An eligible party is a group seated in that area during that period with a working opportunity to use the QR ordering flow. Decide in advance how to treat moved tables, combined tables, and guests who leave before ordering. Apply the same rules each time.
A physical table is a piece of capacity. A party is a group of guests occupying it for a visit. If one table seats two separate parties at lunch, it can contribute two eligible parties. If one large party occupies two tables, it is still one party. Your eligible-party count is therefore not limited to the number of physical tables.
Keep these funnel measures separate:
- Scan events: the number of times a QR code is scanned. This includes repeat scans unless your reporting explicitly removes them.
- Menu-viewing parties: eligible parties with at least one attributable QR menu view. A view means the menu opened, not that an order was placed.
- Submitting parties: eligible parties that submitted at least one order through the guest QR workflow.
- Paying parties: eligible parties that paid for at least one QR order through the payment workflow being measured.
- Paid order value: the recorded value of those paid QR orders, reported separately from counts and rates.
These are party-level measures except for scan events and paid order value. If your software reports only sessions, devices, or orders, do not rename those figures as parties. Ask whether visits and orders can be attributed to a table and a party without relying on a guess.
A QR menu alone may let guests read the menu without letting them order or pay. Confirm what the QR code actually opens before treating menu traffic as an ordering funnel. This guide to where QR ordering fits in table service can help you define which parts of service guests handle themselves.
Calculate adoption with matching periods
The following worksheet is hypothetical. It covers one lunch shift in a designated dining area. Assume staff counted eligible parties as they were seated, and the ordering records can attribute menu views, submissions, and payments to those same parties. Every paid party also submitted an order, and every submitting party viewed the menu. For simplicity, all relevant orders and payments were completed during the shift.
| Measure | Result | What it tells you |
|---|---|---|
| Eligible parties | 40 | The denominator for party adoption |
| Scan events | 50 | Activity, including repeat scans; not 50 parties |
| Parties viewing the menu | 32 of 40, or 80% | Reach among eligible parties |
| Parties submitting a QR order | 24 of 40, or 60% | QR ordering adoption among eligible parties |
| Parties paying for a QR order | 20 of 40, or 50% | QR payment adoption among eligible parties |
| Paid QR order value | $180 | Recorded sales value for paid QR orders, not profit |
The table shows two useful ways to read the same funnel. First, compare each party count with the 40 eligible parties. That gives you reach, order adoption, and payment adoption for the service. Second, compare adjacent steps: 24 of the 32 menu-viewing parties submitted an order, or 75%. Of the 24 submitting parties, 20 paid through the measured workflow, or about 83%.
Those step-to-step rates answer a different question from the overall adoption rates. The 75% figure describes what happened after an attributable menu view; it does not mean 75% of all eligible parties ordered. Similarly, 50 scan events divided by 40 parties would produce 125%, but that is an event-to-party ratio, not an adoption rate.
The $180 is the recorded value of paid QR orders in this example. It is not total restaurant sales, profit, or a measure of sales caused by QR ordering. It excludes unpaid submissions and staff-entered orders. It does not deduct fixed costs, processing fees, or exception costs such as refunds; use your own sales and cost records to assess those separately. Do not add the value of submitted orders to paid order value if the same orders appear in both figures.
Keep the observation window consistent. If a party submits near the end of a shift and pays later, either allow a defined follow-up window for payment or report that payment separately. Do not compare a full-shift order count with a shorter payment window and call the difference abandonment.
Account for shared phones and staff help
Party-level adoption is useful, but it requires reliable attribution. A family might share one phone and submit a single order. Another party might scan on three phones before one person orders. A guest might reopen the menu to check a description. Those behaviors change scan and session counts without necessarily changing the number of parties using QR ordering.
Decide how to handle multiple orders from one party. For the adoption rate, count the party once when it submits its first qualifying QR order. Keep the number and value of additional orders in a separate order report. That prevents a party ordering another drink from being counted as a new adopter.
Staff assistance needs its own rule. A server explaining where to find the code does not necessarily turn a guest-submitted order into a staff order. But if the server enters the items in a staff-facing system, count that as a staff-entered order unless your stated measure deliberately combines channels. Do not assume every order associated with a QR table was placed by the guest.
The four submitting parties that did not pay through the measured workflow in the example are not automatically failed sales. They could have paid another way, still owed a balance at the cutoff, canceled, or encountered a problem. Check the actual order and payment statuses before assigning a reason. Likewise, a paid order value is not a count of deposits or a processing-fee total.
Ask a prospective provider how it identifies a table, how it handles a party that moves, and whether a staff-entered order can be distinguished from a guest-submitted order. If the system cannot connect activity to parties, report the available figures honestly: for example, menu sessions and submitted QR orders, alongside a separately counted number of eligible parties. Do not present a session-to-party ratio as a verified party adoption rate.
Choose one service test from the pattern
In the hypothetical lunch shift, 32 parties viewed the menu and 24 submitted an order. That leaves eight viewing parties without a recorded submission. If the restaurant's goal is to increase guest-submitted orders, that gap is a reasonable place to investigate. It does not establish that menu design, staff instructions, price, or any other single factor caused the gap.
Choose one change that fits the service. For example, a host could give every eligible party the same short explanation that the code opens the menu and can be used to place an order, while still offering the normal staff-assisted option. Compare the same measures over several similar lunch shifts, using the same area, eligibility rules, and payment window. Note material differences such as staffing or an unusual group booking. A change in the rate is a signal to investigate, not proof that the explanation caused it.
Before trying the change with guests, run a simulated check with staff using a safe practice environment. Confirm that the code opens the intended flow, the table identity is clear, and staff can tell what would happen after submission. The simulation must not trigger a real card payment, guest message, or courier dispatch. Ask the provider how to disable those actions or use a suitable test setup.
A live service pilot is different: guests use the normal workflow and real orders may be placed and paid. Prepare staff to monitor orders, recognize payment status, and use the established fallback if a guest cannot or does not want to use a phone. Review exceptions after the shift rather than treating them as proof of a software failure or a lost sale.
Turn the worksheet into a buying requirement
Bring your definitions to a demonstration. Ask the provider to show the guest path from scan to menu, submission, and payment; then ask what staff see at each step. Can the team identify the correct table, distinguish a submitted order from a paid one, and handle an order that needs attention? Can you export or otherwise review the figures for your chosen service period?
Also ask what happens when guests share a phone, place another order, move tables, or choose to pay a server. A useful report should match the decision you want to make. If it cannot count parties, determine whether staff can count eligible parties consistently and whether the remaining reports still answer a useful question.
Compare reporting needs with the service and cost questions in this QR ordering system guide. Fleksa's QR ordering lets guests scan, order, and pay at the table in a browser without downloading an app. Ask how the particular reporting and handoff you need would work in your setup rather than assuming that every funnel measure is available.
Next step: Write down your eligible-party rule and the four figures you need for one service period. Compare those requirements with Fleksa and ask for a demonstration of the relevant ordering, payment, and reporting workflow.
Frequently asked questions
What is a useful QR ordering adoption rate?
Divide the number of eligible parties that submit at least one guest QR order by the total eligible parties in the same period. State the period, area, and eligibility rules alongside the result.
Can QR scans be higher than the number of eligible parties?
Yes. Guests can scan more than once, and several people in one party may scan. Scan events measure activity, not unique parties or orders.
Does a submitted order count as a paid sale?
Not necessarily. Track submission and payment separately, using a consistent payment window. Check canceled, unpaid, and differently paid orders before interpreting the gap.
