Yes, a restaurant POS can support a clear substitution workflow, but you should ask the vendor to demonstrate the exact swaps your staff need. The key question is whether an approved change appears at the right price on the guest check and as an unambiguous instruction for the kitchen. Check both results on every ordering device or channel you plan to use.
Start with one dish, one free swap and one paid swap. A button labeled “substitution” is not enough: the check needs to show what the guest owes, while the kitchen needs to know what to remove and what to prepare instead. Then check whether a manager can trace the change later without reconstructing the order from memory.
Set your substitution requirements
Choose a dish your team changes often. Write down its standard ingredients, which swaps you approve, and whether each swap is free or carries an additional charge. Keep this list separate from open-ended requests that require a manager’s judgment.
For example, a server might be allowed to replace a side salad with vegetables at no charge, or with a premium side for a stated upcharge. A request to replace the main protein may need approval or may not be offered at all. The POS workflow should make that distinction clear enough that staff do not invent a price during a busy shift.
Assign an owner before evaluating systems. The menu manager can define the allowed swaps and prices; a kitchen lead can check whether the preparation instructions make sense; and the person responsible for the POS can check setup and reporting. Decide who can approve an exception and how the server will record that approval.
Also identify where the order starts and where it ends. A dining-room order might be entered on a handheld device and sent to a kitchen display or printer. An online guest may see a different menu. If a swap is offered in more than one place, check each path rather than assuming the same settings carry over. Your restaurant hardware choices matter because the actual screen and printer layout affect what staff can see and enter.
Compare allowed swaps and price differences
Give each vendor the same short requirements sheet. Include the dish, its standard ingredients, the free and paid alternatives, the expected guest-facing wording and the kitchen instruction. Ask the vendor to show the workflow on the devices and channels in your quote, using the configuration you would receive.
For each swap, ask how staff select it, whether the original ingredient is explicitly removed, and whether the replacement and price appear together. Can staff choose only one alternative when the dish has one side? Can an unauthorized combination be blocked, or must the team rely on training? If a guest changes their mind before the order is sent, ask how the correction appears on the check and kitchen ticket.
Toast lists restaurant POS, hardware, online ordering, payments, kitchen display and integrations. Square offers restaurant point of sale and related payment and ordering tools. Fleksa offers a restaurant POS alongside direct ordering, reservations and related tools. Ask each vendor to demonstrate your substitution rules; these product descriptions alone do not establish how a particular swap is configured or reported.
Separate a configured swap from a free-text note. A note may communicate a special request, but ask whether it changes the price, appears on the guest check and can be found in reports. If staff must add an extra charge separately, decide whether that extra step is acceptable and who checks it. A workable manual process can still carry risk when the restaurant is busy.
Use the same scope for every comparison: counter or table service, staff devices, online ordering if relevant, and the kitchen’s actual output. Mark a case as unknown when the vendor cannot show it in that scope. Ask for a written follow-up rather than treating a verbal “yes” as a completed demonstration.
Run the free and paid swap test
The following is a hypothetical menu and test, not a result from any POS. A chicken plate costs $18 and normally comes with rice. The restaurant approves a free swap from rice to vegetables and a $3 swap from rice to a premium side. The expected plate prices are $18 and $21 respectively. These are guest-facing menu prices, not a cost or profit calculation: fixed operating costs, variable ingredient costs and exception costs are excluded.
Prepare the scenario in a vendor-provided practice environment or another isolated setup. Confirm that the demonstration cannot take a real payment, send a guest message or dispatch a courier. Use a simulated payment state if needed; do not run a real card. If a kitchen printer or display is involved, label the output as a test and keep it out of the live production queue.
- Enter the standard plate. Check that it starts at $18 and that the normal rice instruction is clear. This gives you a baseline for both swaps.
- Enter the free swap. Select vegetables instead of rice. Expect an $18 plate price and a kitchen instruction that makes both the removal and replacement clear.
- Enter the paid swap on the same dish. Select the premium side instead of rice. Expect the $3 addition and a $21 plate price, with the correct preparation instruction.
- Compare the outputs. Look at the staff entry screen, guest check and kitchen ticket or display. Record the actual wording and price on each, not just whether the vendor found a button.
- Check a correction. Before sending the test order, change the paid swap to the free one. The expected plate price returns to $18. Check that the kitchen receives the current instruction rather than conflicting alternatives.
Have the kitchen lead read the output without a verbal explanation. “Vegetables” alone may be ambiguous if the ticket still suggests rice is included. Likewise, a correct kitchen instruction does not fix an incorrect guest charge. Both sides of the order must meet your requirements.
Record the person responsible for each observation and any workaround. For example, if the server must add a separate charge and type a note, write down both actions and who verifies them. Ask whether the workaround behaves the same way on each device. Do not mark a case as passed simply because a knowledgeable demonstrator can make it work once.
Document the decision and unresolved exceptions
The worksheet below shows how to turn the hypothetical requirements into a decision record. Its statuses are examples of how to classify evidence; they are not claims about a vendor or the outcome of a test. Replace them with what your team actually observes.
| Case | Expected result | Status and follow-up | Owner |
|---|---|---|---|
| Free swap | $18 plate; no rice; vegetables shown for kitchen | Pass only if check and kitchen output both match | Kitchen lead |
| Paid swap | $21 plate; no rice; premium side shown for kitchen | Fail if price or instruction is wrong; ask for a corrected setup | POS lead |
| Online order | Same approved choice and expected price | Unknown until demonstrated in the quoted channel | Menu manager |
| Reporting | Manager can identify the swap and its charge | Unknown until a report or order record is shown | Manager |
A pass should mean the observed output meets the written expectation on the relevant path. A fail needs a named owner and a correction or an explicitly accepted workaround. Unknown means there is not enough evidence to decide. Keep unknowns open before signing if they affect a required workflow.
For audit purposes, ask the vendor to show how a manager finds a completed test order, its substitution and any price change. Can the manager tell who entered or changed it? Can the team distinguish a priced swap from a general note? Ask to see the actual order record or report rather than assuming every detail will appear in a summary.
Agree on what happens when a request falls outside the approved list. A manager might approve a one-time change, specify its price and tell the server how to communicate it to the kitchen. Record who approved it and how the instruction and charge will be checked. If the POS cannot capture an approval in the order, decide whether a separate record is practical and who maintains it.
Retest after a menu change, device change or configuration correction, and before enabling a new ordering channel. A simulated check verifies the setup without affecting service. A later live service pilot is different: use it only after the team has agreed on the workflow, trained staff and assigned someone to monitor actual orders and resolve mistakes.
Bring your sample dish, approved swaps and worksheet to a Fleksa POS demo. Ask the vendor to enter both swaps and show the check, kitchen output and order record on the devices and channels you intend to use.
Related guide: How to Test Split Checks Before Buying a POS.
Frequently asked questions
Is a substitution the same as a modifier?
A modifier can be the way a system records a choice, but the buying question is more specific: does the approved swap remove the original ingredient, add the replacement and apply the intended price?
Should a free swap appear on the guest check?
Decide what wording makes the order clear to your guests, then ask the vendor to show it. Even when the price stays the same, the kitchen still needs a clear instruction.
What if the POS needs a manual workaround?
Document the extra steps, who checks the charge and instruction, and how managers find the change later. Accept the workaround only if it is practical for your team and meets your requirements.
