Yes, guests can build a meal deal without unintentionally paying separate-item prices if the kiosk offers a clearly priced bundle and carries that price through order review. The buying question is whether the system can do that with your choices, substitutions and kitchen workflow. Ask the vendor to demonstrate it before you commit.
Start with one common meal. Write down what the guest must choose, what is included and what costs extra. Then compare the expected total with the total shown at each step. A single-item modifier test is not enough: this test covers the price relationship between a main, a side and a drink.
Map the meal before configuring the kiosk
For the following hypothetical example, a restaurant wants to offer a chicken sandwich meal for $12. The meal includes one standard side and one standard drink. The sandwich also sells separately for $9, the side for $3 and the drink for $2. A premium side costs $1 extra when selected in the meal.
The operator decides that all three choices are required for the $12 meal. A guest who does not want a side or drink can buy individual items instead. That is a business rule for this example, not a rule every kiosk must use.
Turn those decisions into a short configuration brief:
- Entry point: A guest can choose the meal as a named menu item, rather than having to discover a discount after adding three items.
- Required choices: One sandwich, one side and one drink must be selected before the meal can be added.
- Included choices: Standard sides and drinks carry no additional charge within the meal.
- Exception: The premium side adds $1, shown before the guest confirms the order.
- Separate purchases: Individual menu items remain available at their own prices.
Ask how the kiosk represents that bundle in its menu configuration. Can the price belong to the meal while the kitchen still receives each component? Can staff change an included option later without rebuilding the whole menu? A demo should show the actual choices and order review, not just a menu screen with a meal photo.
Fleksa's restaurant kiosk supports browsing, item customization and order review. For a specific bundle, ask to see how its required choices, price rules and exceptions would be configured.
Compare bundle and separate-item totals
The worksheet below records the expected menu prices for the hypothetical meal. Use the same structure during a demonstration: put the vendor's displayed total beside the expectation and note any difference.
| Guest selection | Expected total | Comparison | What to check |
|---|---|---|---|
| Standard meal | $12 | Separate items: $9 + $3 + $2 = $14 | Meal remains $12 at order review |
| Meal with premium side | $13 | $12 meal + $1 upgrade | Upgrade appears once and is labeled |
| Sandwich and standard side only | $12 | $9 + $3 as separate items | No drink is added or charged |
| Sandwich, side and drink added separately | $14 | Three separate menu prices | Check whether a meal option is offered |
The standard meal saves $2 against the three stated separate-item prices. The sandwich and side happen to total the same $12 as the meal, but that purchase does not include a drink. The kiosk should not imply that the two selections contain the same items.
These figures are menu-price comparisons only. They exclude tax, payment processing and other operating costs, including fixed costs such as hardware and installation, variable costs such as transaction fees, and exception costs such as refunds. They do not show profit or the all-in cost of operating the kiosk.
Ask the vendor what happens when a guest adds all three items separately. Does the kiosk offer the meal, apply a bundle price automatically, or leave the items at $14? Any of those behaviors needs to be visible and consistent with the restaurant's policy. Do not assume an automatic conversion exists. If it does, check that the guest can still understand which items were grouped and whether the price changed.
Also look at the order-review screen. A meal name and $12 total are useful, but the guest should be able to see the chosen side and drink. If the screen shows three individual prices as well as a meal total, ask how it avoids making the guest think both amounts will be charged.
Test substitutions, removal and required choices
Run the checks in a simulated or vendor-provided practice environment. Confirm first that it cannot take a real card payment, send a guest message or dispatch a courier. A practice order should also be kept out of the live kitchen queue, or clearly routed to a test destination.
Begin with a standard meal. Select each required component and review the order. Record the displayed total and the listed items. Then change one choice at a time:
- Leave a required choice unfinished. Try to add the meal without a drink. For this example, the expected result is a clear prompt to choose one; the incomplete meal should not proceed as the $12 bundle.
- Choose the premium side. The extra $1 should be visible during selection and the meal total should be $13 at review. Switch back to a standard side and check that the total returns to $12.
- Remove a component after adding the meal. Try removing the drink from order review. Ask whether the system blocks removal, asks the guest to replace it, removes the whole meal, or reprices the remaining items. For this example, an incomplete bundle should not remain in the cart as though it still includes all three components.
- Change the quantity. Add two standard meals with different sides. The expected total is $24, and each meal should retain its own selections.
- Remove the meal. Delete one of the two meals. The remaining standard meal should total $12, with no orphaned side, drink or upgrade charge.
These are acceptance criteria for the example, not promises about a particular product. If your policy allows guests to remove a component without a price change, write that down instead and check that the kiosk explains it. If a vendor cannot support a required rule, decide whether to simplify the offer or keep it off the kiosk.
Test awkward paths as well as the intended path. Guests may go back to a previous screen, change a selection twice or abandon a meal and add separate items. A correct first screen does not help if an old upgrade charge remains in the cart.
Check kitchen output and record the decision
A guest-facing total can be correct while the kitchen receives an unclear order. In the simulation, inspect the order as it reaches the POS and, if used, the kitchen display or test printer. For the premium-side meal, staff should be able to identify the sandwich, the premium side and the drink, along with any preparation choices the restaurant needs.
Ask how the bundle appears in the restaurant POS system and on a kitchen display system. Does the kitchen see one meal with components underneath, separate lines, or another format? If two meals contain different sides, can staff tell which side belongs to which meal? Confirm the answer with the people who prepare and hand off orders.
Keep a simple acceptance record for each path: the selection, expected total, displayed total, order-review wording, kitchen output and result. Mark a path as passed only when the price and operational details both match the restaurant's rule. Record unresolved differences and ask who would correct them before launch.
For guest-visible savings, compare like with like. In the standard example, a $2 saving is accurate only against the stated $14 price of those three separate items. Ask whether the kiosk can display that comparison clearly; if it cannot, use a straightforward $12 meal price rather than relying on a savings message the guest cannot verify.
After the simulated checks, plan a controlled live service pilot only when staff are ready to monitor actual orders and handle corrections. Live orders can involve real payments and kitchen work, so use a staffed fallback and review discrepancies promptly. Include installed hardware, software, setup, payment compatibility and support in the buying decision. The kiosk break-even guide can help frame that broader cost discussion.
Next, take your meal map and acceptance record to the vendor. Compare your kiosk requirements with the workflows available from Fleksa, and ask for a demonstration of your exact bundle before choosing a launch date.
Frequently asked questions
Should a meal deal be a separate kiosk menu item?
It can be a useful way to make the bundle easy to find and price. Ask the vendor to show how guests select components and how the final price appears before deciding on the configuration.
What if a guest adds the meal components separately?
Check whether the kiosk offers or applies a bundle price, or keeps the separate-item prices. Choose the behavior that fits your policy and make sure the guest can see the resulting total.
Can we test a meal without taking a real payment?
Ask for a simulation or practice environment that does not process a card, send a guest message or dispatch a courier. Check the guest screen and test kitchen output there before considering a live service pilot.
