To test restaurant kiosk session privacy, complete a simulated order with fictional details, leave the kiosk as a departing guest would, and approach it as the next guest. Check every guest-accessible screen and any guest-facing printed output for information from the first order. The kiosk passes only if the next guest cannot see those details through the agreed paths.
Run the demonstration without a real payment, guest message, or courier dispatch. Ask the vendor to show how the simulation reaches a representative completed-order state, then have a restaurant manager inspect the kiosk without help from the person operating the demonstration.
Decide what the next guest must not see
Start by listing the information a guest could enter or select. Depending on the workflow, that might include a name, phone number, email address, order items, modifiers, pickup details, tip selection, or a receipt choice. Some details identify a person directly; an unusual order or a pickup name can also reveal information the next guest has no reason to see.
Separate the source of each detail from where it might reappear. A name might be typed into an order form. An item and its modifiers come from the guest's menu selections. A receipt option might be selected near the end of checkout. Look for those inputs on the start screen, menu, cart, checkout, confirmation screen, and any screen reached by going back.
Include printed output in the boundary of the test. A receipt left in a guest-accessible printer tray may expose the last order even if the screen resets correctly. Decide who is responsible for removing or controlling that output, and whether a guest could pick it up before staff notice.
This test is about what happens after a completed order. An abandoned cart is a separate case: it raises questions about how long an unfinished order should stay open. The cart management workflow can help frame those questions, but a cart timer alone does not prove that completed-order details disappear.
Write down the intended guest journey before the demonstration. For example: the first guest finishes, takes any receipt, walks away, and the next guest starts an order. Then add a second path in which the first guest leaves printed output behind. These paths tell the vendor exactly what you expect to inspect.
Use a decision worksheet with a fictional order
The following example is hypothetical. Assume the demonstration offers a simulated completion path, a guest-facing receipt output, and fields for a pickup name and phone number. These are test assumptions, not claims that every kiosk offers those options. If a field is not part of your intended setup, substitute another identifying input your guests will actually use.
Enter the fictional name “Casey Sample,” the fictional phone number “202-555-0147,” and an order for a veggie sandwich with no onions. Select a receipt option if the proposed setup includes one. Do not use a real guest's details or a real card. Ask the vendor to prevent any actual message, payment, or dispatch while showing the screen state that follows completion.
The worksheet compares two possible observations. It is not a record of a test result. Record what the manager can actually see, rather than assuming a reset happened because a confirmation message appeared.
| Checkpoint | Outcome A | Outcome B | Decision |
|---|---|---|---|
| Next guest's start and cart screens | No Casey Sample details or prior items visible | Prior name or sandwich remains visible | A can proceed to the other checks; B fails |
| Back and receipt paths | No prior details accessible from guest controls | Back or receipt view reveals the prior phone number | A can proceed to the print check; B fails |
| Guest-accessible print output | No prior details remain accessible after the agreed handoff | A prior receipt with the name and order remains in reach | A passes this check; B needs a controlled handoff and retest |
Outcome A supports choosing the workflow only if all agreed paths pass, including the printed-output check. Outcome B changes the decision: do not approve that configuration for guest use until the vendor and restaurant agree on a correction and the manager repeats the demonstration. A clean start screen does not outweigh a phone number visible through another guest control.
For printed output, be specific about the proposed fix. If staff must collect each receipt, ask who covers that task during a rush and what happens when the kiosk is unattended. If the vendor suggests changing the output or its location, ask to see the revised setup rather than treating the suggestion as a completed fix.
Run the demonstration from the next guest's position
Assign the restaurant manager as the observer and exception owner. A vendor representative can operate the simulation, but the manager should make the second pass through the kiosk. That separation matters: the person who knows the system may avoid a screen an ordinary guest would try.
- Agree on the exact configuration, including screens, receipt behavior, and any staff handoff. Ask the vendor to explain how the simulated completion represents a completed order in that configuration.
- Enter the fictional details and complete the simulated order. Confirm that the demonstration cannot charge a card, send a guest message, or dispatch a courier.
- Let the kiosk reach the state a real next guest would encounter. Do not let the operator clear data manually unless that staff action is an explicit part of the proposed workflow.
- Have the manager approach as the next guest. Inspect the screen, begin a new order, open the cart and checkout, and use available back and receipt controls. Look for the fictional name, phone number, items, and selections.
- Inspect guest-accessible printed output under both agreed handoff conditions: when the first guest takes it and when it is left behind. Record whether staff action is needed to keep it from the next guest.
- Record each observation and repeat after any configuration or workflow change. If a path cannot be demonstrated, mark it unresolved rather than passing it.
Also ask to see the order's expected destination on the staff side, where appropriate. A restaurant POS system may need order information for staff to prepare or manage an order; the question here is whether that information is exposed to a later guest. Agree on which screens and print locations are guest-accessible before judging the result.
A simulation is a buying check, not a live service pilot. If you later pilot the chosen setup during service, use a separate plan with staff coverage and a way to stop the kiosk if an issue appears. Do not treat a simulated result as proof that every real-world interruption has been covered.
Set a pass rule and an exception owner
Put the acceptance rule in writing before the demonstration. A practical pass is: after the simulated completion and the agreed handoff, the manager cannot find the prior guest's fictional identifying details or order selections on any tested guest screen, through the tested controls, or in guest-accessible printed output. Every agreed checkpoint must be demonstrated.
Mark the result as a fail if any prior detail appears where the next guest can see or retrieve it. Mark it unresolved if the vendor cannot show a representative completion, a relevant screen, or the proposed print handling. Neither result should be converted into a pass based only on a verbal assurance.
The manager owns the exception: record the affected path, the detail exposed, the configuration, and the vendor's proposed correction. Keep the description factual—for example, “prior phone number visible after selecting back”—rather than recording a real guest's information. Ask the vendor who will make the change and when a repeat demonstration can happen.
Before signing, ask how the proposed workflow behaves after a restart or interruption, and which staff actions it depends on. Add any path important to your restaurant to the checklist. For a restaurant kiosk, also compare the privacy workflow with the practical needs of the counter: staff availability, accessible use, payment compatibility, and what happens when the kiosk cannot take an order.
Next, take your completed checklist to Fleksa and compare your kiosk requirements with the proposed setup. Ask for a demonstration of each relevant path and confirm current support before choosing a workflow.
Frequently asked questions
Is a blank start screen enough to pass?
No. Check the cart, checkout, back and receipt controls, and guest-accessible printed output. The next guest may reach prior details from a screen other than the start screen.
Should we use a real payment to complete the test?
No. Use a simulated completion with fictional details, without a real payment, guest message, or courier dispatch. Ask the vendor to explain how that simulation represents the completed-order state.
What if the screen passes but a receipt is left behind?
Treat the printed output as an exception. Agree on a reliable way to keep it out of the next guest's reach, then repeat the relevant check before approving the workflow.
