Yes, a POS can sell a meal with choices while keeping the customer price and kitchen instructions clear—but you need to see how each system handles your particular meal. A button labeled “combo” is not enough. Check what happens when a choice is missing, a side sells out, or a guest pays for an upgrade.
The buying decision is whether staff can enter the meal accurately, the kitchen can prepare it without guessing, and your reports show the quantities you need. Ask each vendor to walk through the same sample orders and show the resulting screen, receipt, kitchen output, and reports.
Start with one meal and a clear price rule
Use a meal that resembles something you actually sell. For the examples below, imagine a $12 chicken sandwich meal. It includes one sandwich and one required side: fries or a salad. A guest can replace the regular fries with large fries for $2 more. The salad has no upgrade in this example.
That gives you three valid versions: sandwich and regular fries for $12, sandwich and salad for $12, or sandwich and large fries for $14. The $12 is the fixed menu price for the meal; the $2 is the variable upgrade price. The example excludes tax, payment processing, delivery, and other operating costs. There are no added exception charges in the stated rules. These are customer prices, not a calculation of profit or total cost to operate.
Write down what each person needs to see. A cashier needs an obvious way to select the side and explain the upgrade. A guest needs a clear total. The kitchen needs to know which side and size to prepare. A manager needs a report that distinguishes the meals sold from the individual food items prepared.
Give vendors the same rules before a demonstration. Avoid letting the setup drift into a different offer, such as a sandwich with an optional side charged separately. That might produce the right total in one order while failing to enforce the meal you intend to sell.
Check required choices and sold-out sides
First, try to add the meal without choosing a side. Can the order be completed, or does the screen require a selection? A useful result is one that matches your operating rule and tells the employee what to do next. If the system permits an incomplete meal, ask whether a setting changes that behavior and who can change it.
Next, select regular fries and then select the large-fries upgrade. Confirm that the order contains one side, not both sizes. The total should change from $12 to $14. Remove the upgrade and check that it returns to $12. These checks matter because a correct-looking initial order does not prove that edits recalculate correctly.
Now mark fries unavailable for the demonstration and try to order them. Ask the vendor to show what the cashier sees and whether the unavailable choice remains visible, can still be selected, or requires a menu change. If you take orders through more than one channel, ask how availability is updated in each one and who is responsible for it.
Finally, replace fries with salad before completing the order. Under the sample rules, the total should be $12 and the kitchen should see salad rather than fries. Ask what happens if staff make that replacement after the order has already reached the kitchen. Can the kitchen distinguish the change from a second side? Does someone need to communicate it separately?
Record the observed result beside the vendor’s explanation. If a representative says a setting can enforce a rule, ask to see it enabled and repeated. If the outcome depends on a later configuration or another product, note that as an open question rather than marking it as a pass.
Match the customer price to the kitchen instructions
A guest-facing receipt and a kitchen ticket serve different purposes. For the upgraded meal, the customer should be able to understand the $14 total. It could be displayed as a $12 meal plus a $2 upgrade, for example. Whatever the layout, ask whether staff can explain it without doing extra arithmetic or adding an unintended side charge.
The kitchen needs the components: one chicken sandwich and one large fries. It should not have to infer the side from a price or treat the $2 upgrade as another food item. Ask to see the actual ticket or kitchen display output produced by the sample order, including how a changed selection appears.
Consider a decision-changing exception: the receipt correctly totals $14, but the kitchen output says only “chicken meal,” with no side or size. The price passes, but the order is not ready for reliable kitchen use under the sample rules. Ask whether the missing detail can be shown through configuration, then repeat the order. If the kitchen still needs staff to call out every side, count that manual step as part of the workflow you are buying.
Run the demonstration as a simulation in a practice environment. It must not take a real card payment, send a guest message, or dispatch a courier. If you later run a live service pilot, agree on staff responsibilities and handling of real orders separately; a practice result alone does not prove the process will work during a rush.
Use an acceptance matrix to compare results
The matrix below turns the sample meal into specific pass conditions. The quantities are the food items expected from each individual order, not ingredient deductions or a promise that a particular inventory system will update. Ask vendors to show the corresponding report and explain what its counts mean.
| Scenario | Expected customer price | Expected food quantities | Evidence to inspect |
|---|---|---|---|
| Regular fries selected | $12 | 1 sandwich, 1 regular fries | Order screen, receipt, kitchen output, item report |
| Large fries selected | $14 | 1 sandwich, 1 large fries | Upgrade line or total, kitchen output, size-level report |
| Fries replaced with salad before completion | $12 | 1 sandwich, 1 salad; no fries | Edited order, receipt, kitchen output, item report |
| No side selected | No completed sale under the sample rule | No completed-order quantities | Prompt or other block preventing completion |
Use the rows one at a time, then check a small batch. If one order is regular fries, one is large fries, and one is salad, the expected sales total is $38 before the excluded costs: $12 + $14 + $12. The expected food count is three sandwiches, one regular fries, one large fries, and one salad. Three meals sold and three sandwiches prepared are different measures; both can be useful.
Ask whether the report counts the meal, its components, or both, and whether an upgrade replaces the regular side in the count. A report that shows three meals but cannot distinguish the sides may be sufficient for a sales summary, yet insufficient for a manager who uses side counts to plan prep. Check the report’s filters and treatment of canceled or edited orders before relying on it.
Mark each result as pass, fail, or needs follow-up. Keep a copy of the demonstrated output or a written explanation with the quote. A verbal “yes” is less useful than an example showing which screen, ticket, or report satisfies the rule.
Compare the whole workflow before signing
Fleksa offers a restaurant POS connected with direct ordering, reservations, and related tools. Toast lists restaurant POS, hardware, online ordering, payments, kitchen display, and integrations. Square offers restaurant point of sale and related payment and order tools. Use the same meal matrix for each vendor rather than assuming a listed product handles every bundle rule.
Include your actual service channels in the discussion. If a meal is sold at the counter and through direct ordering, ask to see how the choices, availability, price, and kitchen instructions work in both places. Also ask who maintains the menu and whether changing a side in one place changes it elsewhere.
Request a written quote for the equipment, software, setup, and other services needed for the demonstrated workflow. Separate quoted processing fees from the rest of the operating cost, and ask about charges for changes or additional components. Contract duration, cancellation terms, processor requirements, and offline behavior are questions for the vendor, not assumptions to make from a demo. For Fleksa, see its plans for current pricing details; pricing information was checked in November 2026.
Before moving a menu, prepare a restaurant-approved reference with categories, meal rules, modifiers, availability, and prices. Verify the migrated version against it, including the sample orders and reports. A transition can need correction and staff practice; do not build the schedule around an assumption that every order will flow without interruption.
For broader buying context, review these POS questions and consider how the reports fit your restaurant management software. Then request a restaurant POS demo using your sample meal, and ask the vendor to document the outcome for every row of your matrix.
Frequently asked questions
Should a combo appear as one item or several?
The customer may need one understandable meal price, while the kitchen needs separate preparation details. Ask to see both views and confirm that reports provide the meal and component counts your operation needs.
What if a side sells out during service?
Ask how staff mark it unavailable, what customers and cashiers then see, and whether the change applies across your ordering channels. Also agree on how the kitchen receives a replacement made after an order is sent.
Is a correct receipt enough to approve a combo setup?
No. Check required selections, edits, kitchen instructions, and reported quantities as well. A correct total can still accompany an incomplete kitchen ticket or an unhelpful item report.
