Staff can prepare the correct number after a delivery order changes only if the updated quantity reaches the people doing the work, in time for them to act. Test the complete path: the order source, any integration or middleware, the POS, and the kitchen screen or printed ticket. Then check that someone can recognize and acknowledge the change.
A correct POS total alone is not enough. A kitchen may still be working from an earlier ticket. Equally, a visible alert is not enough if it does not show whether the kitchen needs to make more or stop making an extra item.
Set the requirements around your delivery workflow
Start with the delivery channels, locations, devices and kitchen process you actually use. An order might enter through a marketplace or a direct ordering site, pass through an integration, and appear on a restaurant POS before the kitchen sees it. Write down every step, including a tablet or printer that staff consult when the main screen is busy.
Ask the person responsible for delivery operations to own the decision. Include a shift lead and someone who prepares or packs orders. The owner can approve the purchase, but the people on the shift need to be able to follow the change without guessing.
Agree on the timing that matters. A change before preparation starts is different from one received after an item has been cooked or packed. Ask each vendor which changes the source channel permits, when it permits them, and what happens downstream. If a change cannot be sent at a particular stage, the team needs a clear exception process rather than an assumed automatic update.
Define success in plain terms:
- The updated order can be matched to the original using its order ID or another unique identifier.
- Staff can find the old and new quantities, or otherwise reliably identify what changed.
- The relevant item, modifiers and line amount are correct on the systems used to prepare and check the order.
- A responsible person knows whether work has started and acknowledges the action needed.
Check the actual setup, not just a product name. Otter describes an Order Manager that consolidates online and manual orders on a tablet, with automatic acceptance, printing and POS connections. Ask how an amended quantity appears on the specific channel and POS you would use. Fleksa’s integration directory distinguishes live connections from those available on request; confirm availability for your location and configuration.
Compare the original and amended order
Use one clearly marked sample order and follow it through every device in scope. Note the source order ID, item name, modifier, original quantity and amended quantity. Ask the vendor to show whether the change replaces the original line, creates another line, produces an alert or requires a manual step. Those differences affect how a cook reads the order.
The following is a hypothetical simulation, not a vendor result. A delivery order starts with two rice bowls at $12 each, with a $2 extra-protein modifier on each bowl. Before preparation starts, the quantity changes from two to three. The modifier remains attached to every bowl. The expected item-and-modifier subtotal changes from $28 to $42: two times $14, then three times $14.
These figures include the variable item and modifier amounts only. They exclude fixed charges, delivery charges, taxes and any exception costs. The $14 increase is an item subtotal change, not a payment-processing fee or proof that a guest has paid an additional amount. Ask separately how any payment adjustment is handled, without processing a real charge during practice.
The table translates the sample into checks. “Not observed” means the team has not yet recorded a result; it does not mean the system failed.
| Checkpoint | Original | Expected after change | Observed result |
|---|---|---|---|
| Source order | 2 bowls, extra protein on each | 3 bowls, same modifiers | Not observed |
| Item subtotal | $28 | $42 | Not observed |
| POS and kitchen view | 2 bowls under the sample ID | 3 bowls under the same ID; change understandable | Not observed |
| Preparation state | Not started | Prepare 3 bowls in total | Not observed |
Do not count both the old and new displays as separate orders. If a new ticket prints, ask whether it replaces or supplements the earlier ticket and how staff should mark the earlier one. If the kitchen sees only the latest quantity, ask how staff will know that it changed after they had already read it.
Also ask for a decrease, such as changing three bowls to two, and for a change after preparation begins. A decrease can leave an unwanted item in progress; an increase can leave the order short. Record any unsupported case as a limitation, along with the action staff must take.
Run a safe quantity-change simulation
Arrange a demonstration with the vendor using the exact ordering channel, POS connection and kitchen devices you intend to use. Set up a sandbox or another isolated practice environment. Confirm before starting that the simulation cannot charge a real card, message a guest or dispatch a courier. If that isolation is unavailable, use a vendor-controlled demonstration or a walkthrough with sample screens instead.
- Create the original sample. Use a unique test identifier. Record the two bowls, modifiers, $28 item subtotal and preparation state. Capture what appears at the source, POS and kitchen.
- Make the permitted change. Change the quantity to three in the simulated source. Do not change the modifier. Record when and where the change was made.
- Follow the order downstream. At each screen or printer, match the identifier and record the quantity, modifiers and line amount. Note whether an alert appears and whether the earlier version remains visible.
- Check the kitchen action. Have the shift lead explain how a cook would identify the final quantity and acknowledge it. Record the responsible role and the action: prepare three bowls total, not three additional bowls.
- Record the result. Compare expected and observed results. Note any delay, unclear ticket, missing amount or manual workaround, and who would carry it out.
If the simulated preparation state changes to “one already made” before the increase, the instruction becomes two more bowls, for three total. That is a separate preparation-state check; it does not change the order subtotal. Ask how staff record what has already been made and prevent a second person from acting on the old ticket.
Repeat the exercise for each important channel and device combination. An integration that displays the correct quantity on a POS screen has not yet shown that a kitchen printer or screen will communicate it clearly. The guide to direct POS integrations and middleware can help you map who is responsible for each connection.
A simulation checks the workflow without affecting a real order. A later live-service pilot is a separate decision: agree on its scope, staff coverage and exception handling with the vendor first. Do not treat a successful practice run as proof that every live order or channel will behave the same way.
Make the decision and assign exceptions
Use three outcomes for each channel and preparation stage. A pass means the observed quantity, modifiers and relevant line amount match the expected order, and staff can identify and acknowledge the required preparation. A fail means an observed result misses an agreed requirement. Unknown means the team could not observe the result, the setup was unavailable or the vendor has not answered a question. Unknown is not a pass.
For the hypothetical increase, an updated POS showing three bowls would still be a fail against the full workflow if the kitchen continues to act on an unmarked ticket for two and nobody receives the change. If the kitchen view was unavailable during the demonstration, the kitchen result would instead be unknown. Ask for that device to be included before deciding.
A manual workaround can be acceptable if it is specific and reliable for your operation. For example, the shift lead might check the source order, mark an earlier paper ticket as superseded and tell the cook the final total. Write down who performs the check, how the cook acknowledges it and what happens when the lead is away. Consider whether that extra step is workable during your busiest delivery period.
Have the operations owner approve any exception before signing or rollout. Record the affected channels and locations, the workaround, its owner and a retest date or trigger, such as a connection or workflow change. Ask the vendor to demonstrate any unresolved kitchen, payment-adjustment or preparation-state behavior. For contract questions about responsibility or service terms, consult an appropriate qualified adviser.
Next, request a Fleksa POS demo using the sample order and ask the team to show the original, the amended quantity and the kitchen result on the devices you would use.
Frequently asked questions
What if the POS total changes but the kitchen ticket does not?
Treat that as a failed full-workflow check unless an agreed process reliably alerts the kitchen and confirms the final quantity. Identify who owns that step and test it before rollout.
Should we test a quantity decrease as well as an increase?
Yes, where the source channel permits it. A decrease tests whether staff can stop or adjust preparation and avoid packing an extra item. Check the updated line amount and the kitchen’s acknowledgment too.
Can a demonstration replace a live-service pilot?
A demonstration can establish what the configured workflow shows in practice. A separately planned live-service pilot can reveal operational issues during service, but it needs its own controls, staff coverage and exception process.
