To find where guests leave a kiosk order, count how many sessions reach each step and compare each count with the step before it. Start with a defined session, then track item selection, checkout and completion. The biggest drop identifies where to look first; it does not, by itself, explain why guests left.
Keep completed orders with staff help separate from unassisted completions. Also check how the system handles resets and guests who return. Otherwise, a stalled order or a second attempt can make the restaurant kiosk order abandonment rate look worse than the actual guest experience.
Define the events before counting
Ask your vendor which events the kiosk records and whether you can export them by session. A useful funnel needs consistent definitions, not just a daily sales total. Agree on the following four milestones before collecting numbers:
- Session start: A guest begins an ordering attempt, such as by touching the start button. A screen waking up on its own should not count.
- Item selection: The guest adds at least one item to the order. Browsing a menu without adding an item is still an earlier step.
- Checkout: The guest enters the final order and payment flow. Agree on the exact screen or action that marks this point.
- Completion: The order is accepted into the restaurant's order workflow. A payment screen appearing is not a completed order.
These are milestones, not necessarily every screen. A guest might customize an item, review the cart or see an add-on prompt between selection and checkout. If the main funnel points to that stretch, ask whether the system can show finer steps there.
Choose a reporting window. For an outcome report, count each session once at the furthest milestone it reached. For the funnel, count the session at every milestone it reaches. For example, a session that reaches checkout also counts at selection and start. This distinction keeps the step counts useful without counting one attempt as multiple abandoned orders.
Write down what happens when staff help. For example, does the employee finish on the same kiosk, or does the guest move to the counter? The first may be an assisted kiosk completion. The second may be an abandoned kiosk session followed by a counter order. Unless you can link the two reliably, do not call the counter order a recovered kiosk sale.
Build a funnel and separate assisted sessions
The following example is hypothetical. Over one reporting window, a restaurant records 100 kiosk sessions. The table shows the number reaching each milestone and the drop from the previous one. It measures sessions, not unique guests or dollars.
| Milestone | Sessions reaching it | Drop from prior step | Question to investigate |
|---|---|---|---|
| Session start | 100 | Not applicable | Are starts triggered only by a guest action? |
| Item selection | 80 | 20 of 100 starts, or 20% | Can guests find and add an item? |
| Checkout | 60 | 20 of 80 selections, or 25% | Where do guests hesitate after adding an item? |
| Completion | 48 | 12 of 60 checkouts, or 20% | What happens during the final order and payment flow? |
The overall session abandonment rate is 52 of 100 starts, or 52%. The largest proportional step drop is between item selection and checkout: 20 of 80 sessions, or 25%. That makes the screens between those milestones the first place to investigate. It does not prove that customization or any other particular screen caused the drop.
Suppose eight of the 48 completed sessions required staff help on the kiosk. Report 40 unassisted completions and eight assisted completions, alongside 52 sessions without a kiosk completion. The assisted eight are part of the 48, not additional orders. You can also report the unassisted completion rate as 40 of 100 starts, or 40%.
Use a simple staff mark or another agreed method to identify assistance, and ask whether the report can attach that mark to a session. Staff should not have to guess after the rush. Assistance may be useful service rather than a failure, but a high count at one screen is a reason to watch that screen more closely.
Check the numbers against accepted orders in your restaurant POS system, allowing for the agreed reporting window and any other order channels. If the systems cannot isolate kiosk orders or define completion the same way, resolve that difference before treating the funnel as a reliable scorecard.
Check resets and returning guests
A session is an ordering attempt, not necessarily one person. A guest may walk away, return after a reset and start again. Another guest may take over an abandoned screen. The funnel can show attempts that did not complete, but it cannot automatically tell you how many people left hungry or ordered elsewhere.
Ask the vendor what ends a session, whether an idle reset creates a new session ID and whether a resumed order keeps the original ID. Also ask how staff-canceled sessions, payment failures and orders transferred to a counter appear in the report. You are looking for rules that make the numbers interpretable, not a promise that every guest can be tracked.
Before a live service pilot, run a simulation in a practice or sandbox environment. Disable real payment, guest messages and any downstream dispatch. Confirm that practice orders will not enter the live kitchen queue or sales reports. If those safeguards are unavailable, ask the vendor to demonstrate with its own non-live environment.
- Start and leave: Begin one session, add nothing and let the practice session end. Pass if the report shows one start, no selection and one non-completion. Fail if a screen wake-up creates an extra start.
- Reset and return: Begin a session, add an item, let it reset, then begin a second attempt and complete a simulated order. Pass if the report follows the documented session-ID rules and distinguishes the first attempt from the second. Fail if the reset silently merges them contrary to those rules.
- Ask for help: Start an order and have a colleague assist before simulated completion. Pass if the completion and assistance can be recorded without creating two completed orders. Fail if help cannot be identified in the agreed report.
Record the expected and observed result for each check. A failed check is a reporting problem to resolve before comparing busy shifts. If the system cannot connect returning attempts, label the metric as session abandonment and leave guest-level recovery out of the calculation.
After the simulation passes, a live service pilot can use normal guest orders, with staff recording assistance according to the agreed method. Keep practice data out of that pilot. Compare similar service periods and note menu changes, kiosk downtime or unusual staffing, since those can change the mix of sessions.
Observe one likely friction point before changing it
Return to the hypothetical funnel: the 25% drop after item selection is the highest proportional drop. Choose that stretch for observation first. Ask staff to note the last visible screen when a guest pauses, asks for help or leaves. Avoid collecting card details or other unnecessary personal information.
Use a narrow question, such as: “Can a guest who has added an item find the way to review the order?” Do not assume the answer is a larger checkout button. A guest might be deciding among options, waiting for a companion or changing their mind about the meal.
Set observable criteria before changing anything. For example:
- Pass for navigation: In a practice session, a colleague can add a standard item, reach order review and identify the next action without a verbal prompt.
- Fail for navigation: The colleague repeatedly asks where to go next or cannot reach review using the displayed controls.
- Pass for measurement: The practice report places that attempt in the expected milestones and outcome.
- Fail for measurement: The screen sequence and recorded milestone disagree, so the drop cannot yet be assigned to the right stretch.
If navigation fails and measurement passes, discuss a single screen or menu change with the vendor, then repeat the practice check. If measurement fails, fix the event definition or report first. If both pass but live guests still leave at that stretch, observe more sessions before choosing a change. Neither a practice pass nor a lower abandonment rate proves the kiosk caused a sales increase.
When comparing options, ask how browsing, customization and order review are presented, and whether step-level reporting and assistance marking are available in your configuration. Fleksa's restaurant management software is relevant to the wider workflow; confirm how kiosk orders and reports would fit your setup. Include hardware, installation, payment compatibility and a staffed fallback in the buying discussion. For the broader cost decision, use the kiosk break-even guide.
Next, take your event definitions and one practice scenario to the Fleksa restaurant kiosk team. Compare your requirements with Fleksa and confirm current availability before choosing a workflow.
Frequently asked questions
What is a kiosk order abandonment rate?
For a session-based measure, divide kiosk sessions that did not reach the defined completion event by all kiosk sessions started. State the reporting window and session rules so the number can be interpreted.
Should assisted orders count as abandoned?
Not if staff help the guest complete the same kiosk session. Count it as a completion and report the assistance separately. A guest who moves to the counter may leave an incomplete kiosk session, even if they later buy there.
Does the biggest drop show what caused guests to leave?
No. It shows where to investigate first. Observe the screens and assistance requests in that stretch, then check that the recorded events match the guest journey before making a change.
