Yes. A restaurant can test a suggested addition without obscuring the guest’s intended order, but the prompt needs a clear decline path, an accurate order summary, and an easy way to remove the addition. Judge the prompt on completed orders as well as add-ons accepted. A suggestion that gets more taps but causes more guests to abandon checkout may not be worth keeping.
Start with one relevant suggestion at one point in the order. Then check what happens when a guest accepts it, declines it, changes their mind, or asks for help. Use a simulated order first, followed by a limited live pilot only if the simulated checks pass.
Map one prompt and the path past it
Choose an add-on that makes sense next to the item already selected. A drink suggestion after a sandwich is easy to understand. A sequence of offers for a drink, side, dessert, and upgrade can make a guest work through several decisions before reaching the order review.
For this hypothetical example, a guest selects a $9 sandwich. Before order review, the kiosk offers a $2 drink. The guest can select Add drink or No thanks. Both choices lead to the order review. The sandwich stays in the order either way.
The prompt should show the drink and its price without hiding what the guest has already chosen. The decline option should be easy to see and should not require a second confirmation. A guest who wants only the sandwich should not have to hunt for a way forward.
Ask the vendor to demonstrate the actual screen rather than describing it. Can the operator choose when the prompt appears? Can the guest proceed without accepting? Does declining preserve the original item and its customizations? If the answer depends on configuration, ask to see the configuration that would be used in your restaurant.
Also check the screen from the guest’s position. Is the text readable at the installed kiosk height? Can someone using the available accessibility options identify the offer and decline it? If a guest needs help, staff should know how to assist without placing an unwanted addition in the order.
Compare one relevant offer with repeated interruptions
The worksheet below sets a practical boundary for the hypothetical sandwich prompt. It is not a claim about any particular kiosk product. Use it during a vendor demonstration or a simulated order, and replace the example with a real menu item before making your decision.
| Check | Acceptable result | Do not launch yet if |
|---|---|---|
| Decline the drink | One clear decline leads to review with the sandwich intact. | The guest must accept, dismiss repeated offers, or rebuild the sandwich. |
| Accept the drink | The review shows the sandwich and drink separately, with their prices. | The addition or its price is hard to identify. |
| Change your mind | The drink can be removed before submission and the total updates. | Removing it also removes or changes the sandwich. |
| Continue to checkout | The guest can review the order and proceed without another required offer. | Repeated prompts block the path to checkout. |
The decision boundary is straightforward: if a guest cannot decline once and continue with the intended sandwich intact, do not launch this prompt. The same applies if the guest cannot identify and remove an accepted drink before submitting the order. Fix the workflow or choose a different placement before measuring sales outcomes.
Once the basic path works, compare one offer with a more interruption-heavy flow. Count how many times a guest must make a decision unrelated to the original item. Watch whether the guest can tell which button continues the order and which adds something. A second prompt may be acceptable in one setting, but it needs its own reason for appearing and a clear way past it.
Do not rely on the number of offers alone. A single full-screen prompt that conceals the order may be more disruptive than a small, clearly priced suggestion beside the review. Ask whether the vendor can control placement, frequency, and which items trigger an offer. Also ask what happens when an item is unavailable: can staff turn the suggestion off promptly?
Test totals, removal, and the return to review
Run the following as a simulation, not a live guest order. Use a demonstration or test environment that cannot take a real payment, send a guest message, or dispatch a courier. Confirm those safeguards with the vendor before starting. Do not use a real card or guest contact details.
- Select the $9 sandwich and make an available customization. Record the selection shown on screen.
- Decline the $2 drink. Confirm that review still shows the sandwich and its customization.
- Return to the offer or start a fresh simulated order. Accept the drink and check that review lists both items.
- Remove the drink. Confirm that the sandwich remains and the displayed item subtotal returns to $9.
- Accept the drink again and proceed as far as the simulated order review allows. Check that the guest can still change the order before submission.
In this example, the item subtotal is $11 with the drink and $9 without it. Those figures include only the two item prices. They exclude taxes, payment processing, any service charges, fixed kiosk costs, and exception costs such as staff help or corrections. They are not an all-in operating-cost calculation or a forecast of profit.
Check any actual charges separately in the vendor demonstration. Does the review show the distinction between the item subtotal and the final amount? If a suggested item has options or an additional charge for a modification, can the guest see the resulting price before proceeding?
Ask staff to try less tidy paths too: use the back button after accepting, change a sandwich option, or remove the original item. The guest should not be left with a confusing drink-only order unless that is what they intend. Where the software cannot support a desired behavior, decide whether the remaining workflow is clear enough to use; do not assume a setting exists.
For the broader purchase, kiosk software should also fit the way orders reach the kitchen and the way staff handle questions. Discuss the handoff as part of your restaurant management workflow, including who can disable a prompt and how a staff member corrects an order.
Measure completed orders and opt-ins during a live pilot
After the simulated checks pass, decide whether to run a limited live service pilot. Tell staff when it starts, which prompt is active, and how to report confusion or disable it. Have a staffed ordering option available. Unlike the simulation, a live pilot involves actual guest orders and the normal payment process, so keep the test small enough for the team to monitor.
Track more than acceptance. At a minimum, compare the number of order attempts that reach completion, the number of completed orders containing the suggested item, and staff reports of guests needing help. Define an order attempt consistently and ask what the kiosk can actually report. If it cannot distinguish attempts from completed orders, do not treat those measures as interchangeable.
Consider a separate hypothetical comparison. In one period, 90 of 100 order attempts are completed and 18 completed orders include the suggested item. In another, 82 of 100 attempts are completed and 22 completed orders include it. The second period has four more completed orders with the item, but eight fewer completed orders overall. That is a reason to investigate the interruption, not proof that the second prompt made the restaurant more money.
The counts do not show item margins, the value of the abandoned orders, or whether guests would have bought the drink without a prompt. Different traffic, staffing, and service periods can also affect the comparison. Where practical, compare similar periods and keep the menu and staffing as consistent as possible. Note what changed rather than attributing every difference to the prompt.
Set a stop rule before the pilot. For example, stop if staff repeatedly have to help guests decline or remove the item, or if completed orders fall below the threshold your team has chosen. Review comments alongside counts: a guest may complete an order despite a frustrating prompt. If the results are mixed, revise the placement or wording and repeat the check rather than adding more offers.
For the larger purchase decision, include hardware, software, installation, payment compatibility, kitchen capacity, accessibility, and a staffed fallback. The kiosk break-even guide can help frame costs separately from the prompt test. Then discuss your requirements with Fleksa and ask to see the decline, removal, and review paths in the workflow available for your setup.
Frequently asked questions
Where should a kiosk suggest an add-on?
Choose a point where the suggestion relates to the guest’s selection and does not conceal the route to review. Demonstrate the placement with an actual menu item before using it in service.
Should every guest see the same offer?
Not necessarily. Ask whether offers can be tied to relevant selections and disabled when an item is unavailable. Whatever the targeting, guests should be able to decline and continue.
Is a higher add-on count enough to keep a prompt?
No. Compare it with completed orders, guest confusion, staff intervention, and the economics of the items sold. More accepted additions alone do not establish an increase in revenue or profit.
