Yes—a kiosk can give guests a chance to review and correct an order before they commit, but the screen needs to do more than show a total. Before buying, check whether a guest can see the full cart, change it, return to review and understand exactly what the final button will do.
The distinction matters on a busy shift. A guest who notices the wrong quantity should not have to abandon the order or ask an employee to start again. A guest who sees a discount disappear after an edit should be able to understand the new total before moving on.
Fleksa’s kiosk page describes browsing, customization and order review. Ask to see the exact review and correction flow for your proposed setup rather than assuming every detail works the way your restaurant needs.
Build a cart that exposes common mistakes
Use the following hypothetical cart as a repeatable demonstration. The prices and discount are examples for the test, not Fleksa prices or claims about available promotions. Ask the vendor to reproduce the same logic in a demonstration environment, or use its closest equivalent and note any differences.
The cart has two different items. One has a paid modifier, and the other has a no-charge instruction. A fixed $2 cart discount applies while both items are present. For this exercise, assume there are no other charges. The total includes item prices, the paid modifier and the discount; it excludes payment processing, tax, tips and any other fixed, variable or exception costs.
| Cart line | Calculation | Review-screen check |
|---|---|---|
| 1 chicken sandwich, add cheese | $9 + $1 = $10 | Item, quantity and cheese are identifiable |
| 1 salad, dressing on the side | $7 + $0 = $7 | Item, quantity and instruction are identifiable |
| Cart discount | −$2 | Discount is shown separately |
| Total | $10 + $7 − $2 = $15 | Final amount is easy to find |
The table gives the operator a known answer: two items and a $15 total. The guest should not need to remember choices from earlier screens to check that answer. Look for the full item names, quantities, selected modifications, discount and total together in a readable review. If the cart is longer than the screen, check that guests can scroll through it without losing their place.
Also look at the words used for the salad instruction. An unlabeled symbol or a shortened description may save space but leave the guest unsure whether the kitchen will see the request. The point is not to prescribe one screen layout; it is to make the order understandable to someone who did not configure the kiosk.
Change the cart and return to review
Run the demonstration as a simulation. Use a vendor-provided test environment or a walkthrough that cannot send an order to the kitchen, charge a card, message a guest or dispatch a courier. Do not use a real card payment, guest message or courier dispatch to practice. If the vendor cannot isolate the flow, stop before any action that could create a real transaction.
Start at the $15 review screen and change the sandwich quantity from one to two. Under the hypothetical discount rule, both item types are still present, so the $2 discount remains. Two sandwiches with cheese cost $20; adding the $7 salad and subtracting $2 gives a new total of $25. Check that the quantity, modifier and revised total appear when you return to review.
Next, remove the salad. For this example, the discount no longer applies because the cart no longer contains both item types. The remaining order is two sandwiches with cheese, totaling $20. The review should not leave the old discount or the removed salad on screen. Ask how the guest is told that the discount no longer applies, particularly if the amount changes after they leave an edit screen.
Then change the sandwich back to one and return to review. With no salad and no discount, the example total is $10. This sequence checks both directions: an increase in quantity and a decrease after an item has been removed. It also checks whether the paid modifier stays attached to the right item.
Watch the path as well as the numbers. Can the guest find an edit control beside the item? Is removal distinguishable from reducing quantity? After an edit, does the kiosk return to the cart, or does the guest have to navigate through the menu again? A correction flow can be technically possible and still be difficult to use during service.
Finally, ask what happens if the guest removes the last item. The kiosk should not present an empty cart as a ready-to-submit order. The demonstration should show an understandable way to return to browsing or otherwise recover.
Keep fulfillment and the payable total visible
An accurate food list is only part of the confirmation. A guest also needs to know how the order will be fulfilled. For your restaurant, that might mean a dine-in or pickup choice, a pickup location, or another detail your operation actually uses. Ask the vendor to show the choices supported in your proposed setup.
Set a fulfillment choice in the demonstration, then edit an item and return to review. Check that the choice is still visible and correct. If changing fulfillment affects the order, ask to see the updated details and amount before the guest takes the final action. Do not assume that a choice made early in the flow remains obvious at the end.
The amount due should be distinguishable from a subtotal or a discount. In a real configuration, ask the vendor to show how applicable charges and any optional tip appear before commitment. If a fee or other amount can change later, ask when the guest sees it and whether there is another chance to review. A guest should not have to infer the payable amount from several screens.
Try reading the review as a guest standing at the kiosk, not as the person who built the cart. Can you find the fulfillment choice and total without opening another menu? Are labels readable at the normal standing position? Can a guest return to make a correction without losing the rest of the order? Include staff accessibility observations in the demonstration and ask what alternative assistance is available when a guest cannot use the screen.
This is also a handoff question. Ask how the final, corrected order reaches the restaurant’s ordering workflow, and what staff see when something needs attention. Your restaurant management workflow needs a practical fallback if the kiosk cannot complete an order; the review screen alone cannot solve a service interruption.
Set a pass-or-fail boundary before the demo
Give the vendor the cart and expected results before the walkthrough. Have one person operate the screen and another compare what appears with the worksheet. Record the path and the outcome, not just whether the presenter says an edit is possible.
For this decision, use these acceptance criteria:
- Full review: Both item names, quantities, modifications, discount, fulfillment choice and payable total can be checked before the final action.
- Correction: Quantity changes and item removal are available without rebuilding the entire cart, and the guest can return to review.
- Recalculation: The example totals change from $15 to $25, then $20 and $10 under the stated discount rule. Removed items and ineligible discounts do not remain in the reviewed cart.
- Clear errors: When a required choice is missing or a discount is invalid, the screen identifies what needs attention and gives the guest a way to correct it.
- Clear final action: The button label and surrounding information make it understandable whether the next action submits the order, begins payment or leads to another review step.
Ask the vendor to demonstrate an invalid or incomplete choice in the safe environment. Note whether the message points to the affected item and whether the guest can fix it while keeping the rest of the cart. A generic error with no clear next step is not enough for an unattended ordering station.
Decision boundary: Under these assumptions, treat the kiosk as a fit for this review requirement only if all five criteria pass in the workflow you intend to use. If guests cannot correct an item without rebuilding the cart, cannot see the revised payable total, or cannot tell what the final action does, do not accept the review requirement as met. Ask for a documented alternative or keep looking.
A successful simulation establishes what the demonstrated configuration does in that controlled path. It does not establish how staff and guests will handle every situation during service. If you proceed to a live service pilot, plan it separately with staff present, an agreed fallback and appropriate controls for actual orders and payments.
Compare the workflow before signing
Review-screen performance is one part of the purchase. Get a written quote for hardware, software and installation, and ask about payment compatibility, kitchen capacity and staff support. Your installed cost and service conditions may matter as much as the screen itself. The related kiosk break-even guide can help frame that broader calculation.
Bring the worksheet to your next vendor conversation. Ask to see your required order-review path, including edits and the final action, in the proposed configuration. Compare the workflow and current product fit with Fleksa’s kiosk software, then discuss requirements that need a closer demonstration.
Frequently asked questions
Should guests be able to edit an order from the review screen?
For a practical self-service flow, they should be able to correct the cart and return to review without starting over. Ask the vendor to demonstrate quantity changes, removal and modifier corrections.
What should the final review show?
Check for item names, quantities, modifications, discounts, the relevant fulfillment choice and the payable total. The final action should also make clear what happens next.
Can a simulation prove the kiosk is ready for service?
No. A safe simulation checks the demonstrated workflow without creating real transactions. A separately planned live pilot can show how the setup works with staff and guests during service.
