To check whether kiosk modifier prices are clear, follow one item from its starting price through each selection and into the final order review. At every step, compare what the guest sees with the price you expect. Then remove a paid choice, change the base item, and check the confirmation again.
The key question is not just whether the final total is correct. A guest should be able to understand which choice changed the price and what the order costs before submitting it. Ask each vendor to walk through the same menu example so you can compare the displays, not just the feature lists.
Record the starting price
Start with a simple item that resembles something on your menu. Write down the base price, what is included, and which changes cost extra. Keep the first pass small enough that you can calculate the expected total without relying on the kiosk.
Hypothetical test inputs: A regular meal costs $10 and includes one standard side. A large meal costs $12 and also includes one standard side. Either meal can have a premium side instead for an additional $2. There are no other items in the order. These figures are examples for the test, not Fleksa prices.
For this exercise, fixed costs such as kiosk hardware and software are excluded. Variable transaction costs, taxes, tips, discounts, and exception costs such as refunds are also excluded. The displayed amounts are menu subtotals, not an all-in operating cost or a prediction of a guest's final payment.
Before making a selection, look at the regular meal's displayed price. Can a guest tell that one standard side is included? When the side choices appear, is the premium side clearly marked as an additional $2? A label such as “$2” may need more context if a guest could read it as the full side price rather than an upgrade charge.
Use the sheet below to record what the display should show. The expected order subtotal equals the item subtotal here because the order contains only one item. If you add another item during a separate test, calculate its contribution independently.
| Step | Selection | Expected item subtotal | Expected order subtotal |
|---|---|---|---|
| 1 | Regular meal, standard side | $10 | $10 |
| 2 | Regular meal, premium side | $12 | $12 |
| 3 | Regular meal, standard side again | $10 | $10 |
| 4 | Large meal, standard side | $12 | $12 |
| 5 | Large meal, premium side | $14 | $14 |
The table is an expected-price worksheet, not a claim about what a particular system will display. Record the actual display beside it in your own notes. Mark a difference if the amount is wrong, but also mark it if the amount is correct and the reason for it is hard to see.
Add and remove the paid upgrade
Select the premium side for the regular meal. The expected item subtotal rises from $10 to $12: the $10 meal plus the $2 upgrade. Check the choice label, the item subtotal, and the order subtotal wherever each appears. A guest may look at any of those places to decide whether to continue.
Next, switch back to the included standard side. The item and order subtotals should return to $10. Look for the premium side being removed from the displayed selections as well as from the price. A total that drops without a clear change in the item description can still leave the guest uncertain about what they ordered.
Repeat the change in the other direction. Does the price update when the choice is made, or only after another button is pressed? Either flow can be understandable, but the screen should make the next action clear. Note whether a guest has to leave the item screen to discover the revised amount.
Ask the vendor to show what happens if a guest edits the item after adding it to the order. The important comparison is between the item being edited and the item shown in the order summary afterward. Check that an old upgrade is not still listed or charged when the guest has replaced it.
Do not stop at a demonstration with a staff member narrating every tap. Ask someone unfamiliar with the menu to read the screen and explain the price back to you. Use a simulated order without a real payment, guest message, or courier dispatch. This is a display check, not a live service pilot.
Change the base item
Base-item changes deserve their own pass because a modifier can depend on the item it belongs to. In the worksheet, change from the regular meal with its standard side to the large meal. The expected subtotal is now $12. Then select the premium side: $12 plus $2 gives a $14 subtotal.
Watch both the choice and its price during the change. If the screen keeps a previous side selection, does it show that selection clearly under the new meal? If it resets the choice, does it ask the guest to choose again before continuing? The display should not leave a guest thinking one side is selected while the order summary shows another.
Also ask the vendor to demonstrate a menu rule from your own operation. For example, a side might be included with one meal but unavailable with another. Confirm how the system handles that dependency when the guest changes items. Do not assume that every kiosk supports the same rules or that it will automatically remove an invalid selection.
For a more complete check, return to the regular meal after selecting the large meal and premium side. Work out the expected result according to the behavior you have agreed to test: if the premium side remains selected, the regular meal subtotal should be $12; if the guest deliberately changes back to the standard side, it should be $10. Record which choice is actually visible. The right amount depends on the selection shown, not merely on the direction of the price change.
When comparing systems, give each vendor the same item names, included choices, and prices. Ask which parts of the display your team can configure and which are fixed. That makes a useful distinction between a menu setup issue you can correct and a display limitation you would have to accept.
Verify the final confirmation
Finish the simulated order with the large meal and premium side. Before submission, the order review should make the selected meal, side, and $14 subtotal understandable. Compare that screen with a mock receipt created from your written inputs: large meal $12, premium-side upgrade $2, total menu subtotal $14.
The mock receipt is an arithmetic reference, not proof that the system produces a receipt in that format. Ask the vendor to show the available receipt or order-record view and compare its item details with the confirmation screen. If a receipt view groups the upgrade into the item price, check whether the guest and your staff can still identify the selection.
For an actual order, the payable total may include amounts outside this exercise. Ask where taxes, tips, discounts, and any other charges appear, and whether guests can review the payable total before submitting. Do not add an invented fee or tax rate to the worksheet. Instead, request a separate demonstration using the charges and settings relevant to your restaurant.
Record each issue in a form the vendor can act on: the starting item, the taps made, the expected selection and subtotal, and what appeared instead. Include unclear wording as well as arithmetic differences. Ask whether the issue can be corrected through menu setup, requires a product change, or remains a limitation. Then repeat the same scenario after any proposed correction.
If the kiosk sends orders to other tools, ask to see how the selected item and modifier appear there too. A restaurant POS system and a kitchen display system serve different staff needs: the order record should be understandable to the person handling a price question, while the kitchen needs the correct preparation choice. Confirm the actual connections and views in your proposed setup rather than assuming they work together.
Use the result to make a practical buying decision. If one option shows each change clearly and another requires guests to navigate away to find the revised price, the first may be the better fit for a menu with frequent paid upgrades. Balance that finding against the written hardware, software, and installation quote, payment compatibility, accessibility, kitchen capacity, and a staffed fallback. The kiosk break-even guide can help frame the broader cost discussion; the price-display worksheet answers a narrower guest-facing question.
Next, take the worksheet and one real menu item to a vendor demonstration. Compare the workflow with your requirements when evaluating restaurant software, including the Fleksa restaurant kiosk. Ask to run the same simulated changes before deciding whether to proceed to a separately planned live service pilot.
Frequently asked questions
Should a kiosk show the upgrade price or the new total?
A useful display makes both understandable: what the upgrade adds and what the item or order costs after the change. Check the selection screen and order review rather than assuming one label explains everything.
What if the total is correct but the modifier is unclear?
Flag it. A guest needs to know what they selected as well as what they owe. Ask the vendor whether labels or summary details can be changed, then repeat the same simulated scenario.
Does this test replace a live service pilot?
No. A simulation checks the displayed workflow without a real payment, guest message, or courier dispatch. A separately planned live pilot can assess the process during service, with staff and any real transactions handled under your normal procedures.
