To compare table-service timing before and after a QR pilot, record the same four events for each guest party: seating, initial order, first food delivery and departure. Compare similar services, calculate the median and count long waits. Decide in advance what improvement would justify continuing, and check whether other changes could explain the result.
Measure a guest party, not a physical table. One party may occupy two tables, and one table may serve several parties during a shift. Give each party a separate record so its times stay together.
Set four timestamps everyone can record
Use the same clock or synchronized devices for both periods. Record the actual time of each event, not a rounded estimate at the end of service. A simple sheet can work if staff can fill it in without disrupting guests.
- Seated: The party is seated and ready to begin service. Record the time even if the party was waiting elsewhere first.
- Initial order: The first food order is submitted to the restaurant. For a staff-taken order, use the time it is entered or passed to the kitchen. For a QR order, use submission time, not the time a guest opens the menu.
- First food delivered: The first food item reaches the party. This does not mean everyone has received their meal.
- Departure: The last guest in the party leaves the table. This does not include cleaning or resetting it.
Calculate three intervals: seating to initial order, initial order to first food, and seating to departure. The first shows how long the party took to place an order; the second captures a food wait; the third describes the dining visit. Keep the raw timestamps as well as the calculated minutes so you can correct obvious entry errors.
Agree on edge cases before collecting data. If a party orders drinks first and food later, record the first food order for this comparison. If guests move tables, keep the same party record. If the first dish is shared, its arrival still starts the first-food timestamp. A later second round of ordering does not replace the initial order time.
These measures answer different questions. A shorter order interval does not necessarily mean food arrives sooner, and a longer visit may reflect guests enjoying another course rather than a service problem. If clearing and resetting matter, measure them separately rather than adding them to the departure time.
Compare services that resemble each other
Choose a baseline period before the pilot and a pilot period with similar service windows. For example, compare several Tuesday lunch services with several Tuesday lunch services, rather than a quiet weekday lunch with a busy Saturday dinner. Include every eligible party in those windows, including parties that use a staff-assisted fallback during the pilot.
Record the service date, day, hours, number of parties, party size and relevant conditions alongside the times. Note menu changes, promotions, special events, kitchen disruptions and the number and roles of staff on duty. These notes help explain differences; they are not a staffing plan.
Set an explicit capacity boundary for the comparison. Record the number of physical tables available and whether a section was closed. Also record how many parties were served: table count describes capacity, while party count describes demand. If the dining room has fewer available tables in one period, do not treat the periods as directly equivalent without accounting for the difference.
Keep the menu and service pattern as steady as practical. A new tasting menu, a large private party or a temporary kitchen station closure can change timing independently of ordering method. If a shift is unusual, mark it and review the results with and without that shift; do not quietly remove it because the numbers look unfavorable.
Before a live pilot, run a simulated workflow with staff using test records. Check table identification, handoff and how each timestamp will be captured. The simulation should not trigger a real card payment, guest message or courier dispatch. Then collect baseline and pilot observations during actual service, using the restaurant's normal guest-facing process.
Use a worksheet with a decision boundary
The following example is hypothetical. Assume an owner records 20 eligible parties across comparable baseline lunches and 20 across pilot lunches. Each period has the same number of available physical tables, a similar menu and no noted kitchen disruption. The owner defines a long food wait as more than 20 minutes from initial order to first food.
Before looking at results, the owner sets a pilot decision boundary: continue to a longer evaluation only if the median seating-to-order time falls by at least three minutes, the median order-to-first-food time does not rise by more than two minutes, and no more than four of the 20 pilot parties have a long food wait. All three conditions must be met.
| Measure | Baseline | QR pilot | Decision check |
|---|---|---|---|
| Median seating to initial order | 10 minutes | 6 minutes | Down 4 minutes; meets the 3-minute target |
| Median initial order to first food | 14 minutes | 15 minutes | Up 1 minute; within the 2-minute limit |
| Parties waiting more than 20 minutes for first food | 3 of 20 | 4 of 20 | At the limit of 4 parties |
| Median seating to departure | 52 minutes | 51 minutes | Context only; no pass threshold set |
For each median, sort the 20 party intervals from shortest to longest and average the 10th and 11th values. Count every party above 20 minutes for the long-wait measure; a wait of exactly 20 minutes does not count under this definition.
The example meets the stated boundary, so the owner would continue to a longer evaluation rather than make a permanent decision on these lunches alone. The long-wait count is at the limit, however, so it deserves close attention. Had five pilot parties waited more than 20 minutes, the pilot would fail the boundary even though ordering became faster. The owner could investigate the waits, adjust the workflow and run another comparison.
Choose thresholds that fit your own service before collecting pilot results. A counter-service lunch and a multi-course dinner may need different limits. Use enough comparable services to avoid making a decision from one unusual shift, and report the number of complete party records alongside every summary.
Handle gaps and interpret the result
Keep a record for every eligible party, even when a timestamp is missing. A party missing its departure time cannot contribute to seating-to-departure calculations, but it may still contribute to the first two intervals. Show the number of complete records for each measure. If missing times cluster during the busiest period, the recorded median could make service look faster than it was.
Use a consistent rule for corrections. A first-food timestamp before the order timestamp is an obvious error to investigate against the original record. If it cannot be resolved, exclude that interval from the calculation and note the reason. Do not substitute an estimated time just to complete the worksheet.
Timing alone cannot prove that QR ordering caused a change. Guest mix, menu choices, kitchen workload and staff familiarity can all matter. A pilot can also change more than the ordering method: guests may get different instructions or staff may check on tables at different times. Read the shift notes before attributing the result to the software.
Watch the handoff as well as the clock. Ask whether the order identifies the right table, how staff see it, how payment status is shown and what happens when a guest does not want to use a phone. A quick submission is of limited value if the team has to correct table details or chase unclear orders. The guide to where QR ordering fits in table service can help define that workflow before the comparison.
For a next step, write down your timestamps, eligible service windows and pass boundary, then discuss your requirements with Fleksa. Compare the workflow with its QR ordering software and ask how the data and staff handoff would fit your setup.
Frequently asked questions
Should I compare average or median service time?
Use the median for the typical party, then count long waits separately. An average can be pulled up by a few unusually long visits, while the median alone can hide a poor experience at the slow end.
Does a faster order mean the table will turn faster?
Not necessarily. Food preparation, additional orders and the time guests choose to stay all affect the visit. Measure seating to departure separately, and add reset time only if you define it as a separate measure.
Can guests order and pay through Fleksa QR ordering?
Fleksa lets guests scan, order and pay at the table in a browser without downloading an app. Ask about table identification, payment status and a non-phone fallback for your service model.
