Restaurant POS modifiers can capture required choices, substitutions and prices clearly, but a feature list cannot tell you whether they will work for your menu. During a demo, enter a complete order, change it and follow the result from the cashier screen to the kitchen and final total.
Bring a small test menu and agree on the expected results before the vendor starts. The goal is to see whether a busy employee can enter the guest’s request without guessing what a button means or relying on a note to fix the price.
Build a test menu with a required side and paid extra
Use the following hypothetical menu for a simulated order. The prices are examples, not claims about any POS provider or restaurant. The line totals include the meal and selected modifiers only. They exclude taxes, payment processing, fixed software costs and other operating costs.
- Chicken sandwich meal: $12.00, including one side.
- Required side: fries or salad, with no price difference.
- Optional extra cheese: $1.50.
- Bun substitution: regular bun included, or gluten-free bun for an additional $2.00.
First, select the meal and try to add it to the order without choosing a side. For this menu, the expected result is a prompt to choose one side before the item is accepted. Then try to choose both sides. If your rule is exactly one, the screen should prevent two selections or make the conflict obvious before the order is accepted.
Next, choose fries and add cheese. The item should show the meal, fries and cheese, with a $13.50 line total. Ask the demonstrator to start again and let you enter the same order. Count the decisions an employee must make, not just the taps: a screen with many options can still be workable if required choices and prices are easy to distinguish.
Use this matrix as the expected result, then compare it with what appears on the order screen, kitchen output and receipt preview. A missing side is intentionally an incomplete order; it should not have an accepted line total.
| Guest request | Selections to enter | Expected line total | What to check |
|---|---|---|---|
| Meal, no side selected | None yet | Not accepted | Prompt for one side |
| Meal with fries and extra cheese | Fries; extra cheese | $13.50 | Side and paid extra are visible |
| Meal with salad and gluten-free bun | Salad; gluten-free bun instead of regular | $14.00 | Bun is a substitution, with a $2.00 increase |
| Meal with salad, gluten-free bun and cheese | Salad; gluten-free bun; extra cheese | $15.50 | Both paid changes appear and add correctly |
For the last row, $12.00 plus $2.00 plus $1.50 equals $15.50. If the vendor’s setup produces a different result, ask whether the menu rule can be changed and who would maintain it. A workaround that requires a manager for every ordinary substitution may be a poor fit, even if the math can eventually be made correct.
Test substitutions against the guest request and total
A substitution needs to explain both what is removed and what replaces it. Ask for salad instead of fries and a gluten-free bun instead of the regular bun. On the guest-facing total, the side swap should add nothing under this test menu, while the bun swap should add $2.00. On the kitchen output, staff should be able to tell which side and bun to prepare.
Then ask the vendor to enter “no cheese” on the standard sandwich. That instruction should not create a charge or a credit in this example: cheese is only a paid extra when added. If your real menu gives a credit for removing an ingredient, write the amount and rule down before the demo and test that rule separately.
Look for ambiguous combinations. Can an employee accidentally select both regular and gluten-free buns? Can the system accept both “extra cheese” and “no cheese”? If it can, what warning or review step helps the employee resolve the conflict? Do not assume that a note will override a structured choice or change a price.
Also check quantity. Enter two identical meals with salad, the gluten-free bun and cheese. At $15.50 each, the two meal lines should total $31.00 before the excluded costs listed above. Ask how to change only one meal if the second guest wants fries instead. The staff view should make clear which meal has each side; a correct combined total alone is not enough.
Follow instructions from the order screen to the kitchen
Structured modifiers are useful when a choice has a defined meaning or price. Free-text notes can cover unusual requests, but they depend on someone reading and interpreting them. Compare both paths during the demo rather than assuming they appear in the same place.
Enter the salad and gluten-free bun as structured choices. Add a separate note such as “sauce on the side.” In a simulated kitchen display or print preview, find the item, its choices and the note. Ask the vendor to show the exact view your cooks would use, including any relevant printer or display settings.
Check whether the instruction is attached to the individual meal or to the whole order. If two meals are on the ticket and only one needs sauce on the side, the kitchen needs to know which one. Ask how long notes can be, whether they can be edited and whether staff can distinguish them from modifiers at a glance.
For an allergy-related request, do not treat a POS label as a food-safety procedure. Ask how the instruction is made prominent and how your team will confirm it verbally and handle it under the restaurant’s own procedures. If the screen makes important instructions easy to miss, discuss a safer operating process before relying on it.
Screen size and placement matter too. The same ticket may read differently at the counter and at the pass. Discuss the devices you plan to use when evaluating restaurant POS hardware, and ask to see the relevant layout rather than assuming every configuration looks alike.
Change a selection and check the correction after sending
Start with the $15.50 meal: salad, gluten-free bun and extra cheese. Before sending the order, remove the cheese. The expected line total is $14.00, and cheese should no longer appear as an active selection. Change the side from salad to fries; the total should remain $14.00 and the active side should be fries.
Now use the vendor’s simulated workflow to send the item to a kitchen view. Change the side back to salad after sending. Ask what the cook sees: an updated item, a separate change notice or another clear instruction. Check whether the original fries selection remains visible as history and whether the current instruction is distinguishable from it. The answer matters because a cook may already have started the meal.
Repeat with a price change after sending: remove the gluten-free bun and return to the regular bun. Under this test menu, the current line total should fall from $14.00 to $12.00. Ask how the correction appears to the cashier, the kitchen and on the receipt preview. If a permission, void or manager approval is needed, find out who can perform it during service.
Keep the demo simulated. Use a test order and preview or test-mode kitchen output; do not charge a real card, send a guest message or dispatch a courier. A later live-service pilot is a separate decision: agree on staff training, supervision and an operational fallback with the vendor before using the system for actual guests.
Turn the results into a buying decision
Mark each test as passed, failed or needing a setup change. Record the screen where a problem appeared and the steps needed to fix it. A vendor’s answer that a rule is configurable is useful, but ask for a demonstration of the configuration you would actually need and whether it is included in your quote.
Prioritize failures by their service impact. A confusing side selection that repeatedly sends the wrong food to the kitchen deserves more attention than an extra tap on an uncommon request. A price that recalculates correctly but leaves the old instruction looking active also needs a clear operating answer.
Ask how menu changes are maintained across the channels you intend to use. For example, if a paid extra is updated at the counter, what must someone do to update direct online ordering? Who can make that change, and how can the restaurant check it before guests order? Your answer may affect both training time and the ongoing work of maintaining the menu.
Compare the workflow alongside the written quote, including equipment, setup and ongoing charges relevant to your operation. The guide to no-monthly-fee POS costs offers questions for looking beyond the headline fee. Also consider how menu management fits with your wider restaurant management software.
Ready to try the matrix? Request a restaurant POS demo and bring your own required choices, substitutions, prices and kitchen-ticket requirements. Ask to enter the cases yourself and leave with a written list of any setup questions.
Frequently asked questions
What is a required modifier in a restaurant POS?
It is a choice the order-entry workflow requires before an item can be accepted, such as choosing one included side. Test both a missing choice and an attempt to select more than the permitted number.
Should a substitution be a modifier or a note?
For a recurring substitution with a defined price, test a structured choice so the selection and price can be checked together. Use notes for additional instructions, and confirm that the kitchen can see them on the correct item.
What should happen when a modifier changes after an order is sent?
The current order and total should reflect the change, and the kitchen needs a clear correction. Ask the vendor to demonstrate how the old and new instructions appear and who is authorized to make the change.
