When a guest wants to change a kiosk order already sent to preparation, a staff member should first find the original order and check its preparation status. Then they should agree on the requested change, tell the preparation team what to stop or make, and settle any price difference using the restaurant’s approved payment process. Confirm the outcome with the guest before treating the request as complete.
The critical question for a buyer is whether the kiosk, point of sale and kitchen workflow keep that change connected to the original order. If they do not, staff need a clear fallback. This situation is different from an interrupted payment: the original order has already been submitted, so work on it may already be underway.
Map the request from the guest to the kitchen
Start with an order identifier, not a description of the guest or a guess about what they bought. Staff should be able to locate the original order, see its items and determine who is preparing it. Ask the vendor which identifier appears on the guest receipt, staff screen and kitchen display or ticket. If those identifiers differ, ask how staff connect them during a busy service.
Next, establish who owns the request. One employee should take responsibility for checking the order, communicating the change and closing the loop with the guest. That person may need help from a cashier or kitchen lead, but the guest should not have to repeat the request to each station.
Use the following hypothetical example to evaluate a workflow. A guest has paid for a $12 order: an $8 sandwich and a $4 side. The order has been submitted, and the kitchen has started the sandwich but has not started the side. The guest asks to replace the $4 side with a $3 side and add a $2 drink.
The expected result is one clearly identified order with the sandwich retained, the original side removed, the replacement side and drink added, and a $1 balance resolved. The kitchen must know not to prepare the original side. If the system cannot show the change reliably, the employee needs a direct confirmation from the preparation team and a documented fallback.
Before buying a restaurant kiosk, walk through this request with the actual screens and devices included in the quote. Ask whether staff can edit a submitted order, whether the kitchen sees the revision, and what happens to the original ticket. Do not assume that an item customization option available before checkout also works after submission.
Trace the item changes and the payment difference
Break the request into actions rather than describing it as a single edit. Removing an item, adding another and collecting or returning money may each require a different permission or screen. Ask whether the system retains the original order reference and shows who made the change. Also ask whether staff can see both the original and revised details when resolving a question later.
For the example, the revised food and drink total is $8 + $3 + $2 = $13. The guest already paid $12, so the difference is $1. That is a change in the order total, not a processing fee or a measure of the restaurant’s total operating cost. The example includes item prices only; it excludes taxes, tips, payment processing fees, fixed costs and exception-handling costs. Check how the actual system calculates any applicable amounts before asking a guest to pay.
| Action | Expected record | Observable pass or fail |
|---|---|---|
| Find the order | Original $12 order and its identifier | Pass: staff locate the right order. Fail: staff cannot distinguish it from another order. |
| Remove the side | $4 side marked removed or otherwise clearly canceled | Pass: preparation staff can identify the item to stop. Fail: the original side still appears as an unqualified item to make. |
| Add items | $3 side and $2 drink connected to the request | Pass: both additions reach the people responsible. Fail: either item is missing or cannot be tied to the order. |
| Resolve payment | $13 revised item total, $12 already paid and $1 due | Pass: staff can see how the balance was resolved. Fail: the order appears settled without a visible resolution. |
The table separates the checks that must all work for this particular request. A system that calculates the $1 correctly still fails the kitchen handoff if the old side remains an active instruction. Likewise, a clear kitchen update does not resolve an unexplained payment balance.
Also ask about the reverse case: if the revised total is lower, how does an authorized employee issue and record a refund or other approved adjustment? Find out whether a partial refund is possible, who can approve it and what the guest receives as confirmation. Avoid promising the guest a specific refund method until staff know what the payment setup permits.
Check kitchen notification and reconciliation
Run the example as a simulation before relying on it in service. Use a vendor-provided demo or a safe test setup. Confirm in advance that it will not charge a real card, send a guest message or dispatch a courier. A practice order should not enter a live preparation queue where someone could mistake it for food to make.
Have one person act as the guest, one as the employee and one as the kitchen lead. The employee should find the order, make or record the requested changes and explain the revised total. The kitchen lead should then read the resulting display or ticket without being told what to expect. Ask that person to identify the items to make and the item to stop.
Look for an unmistakable change indicator. Does the preparation team see a revised ticket, an alert, a cancellation plus a new item, or another signal? Does the old instruction disappear or remain visible with a clear status? Can the kitchen acknowledge the change, and can the employee tell whether anyone has seen it? A notification that appears briefly but is missed at a station is not a reliable handoff on its own.
Then inspect the staff and payment records. The simulated result should show the original $12 payment, the revised $13 item total and the $1 balance or its recorded resolution. If the workflow uses a separate adjustment or replacement order, ask how those records are linked. Staff should not need to guess whether the guest paid twice or whether a balance remains.
Repeat the walkthrough for a request made after an item has been prepared. The purpose is not to force the same result; it is to see whether staff can recognize that the cutoff has passed and follow the restaurant’s policy. Record what each person actually sees and where a verbal confirmation is needed.
A separate live service pilot, if you choose one, uses real orders and normal payment procedures. Train the team first, assign a supervisor to handle exceptions, and tell staff when to stop using the workflow. A simulation alone does not establish how a busy shift will perform.
Set a cutoff and a staffed fallback
Choose a cutoff that reflects the work in your kitchen. For example, a restaurant might allow a side swap before preparation starts, but require a manager’s decision once the side is being made. A sandwich already started may stay on the order even if the guest changes another item. Make those distinctions visible to staff, and have them explain the available options to the guest without promising that every request can be accommodated.
If post-submission edits are unsupported or the kitchen cannot receive a dependable update, use a staffed fallback:
- Find the original order and ask the kitchen lead what has started.
- Agree with the guest on what can still change and what the revised charge or refund would be.
- Have an authorized employee record the change using the restaurant’s approved adjustment or replacement-order process.
- Tell each affected preparation station exactly what to stop and what to make. Get an acknowledgment, rather than assuming the message was seen.
- Resolve the payment difference through the approved payment workflow and connect the records so another employee can follow them.
- Confirm the final order and payment outcome with the guest.
If a replacement order is necessary, ask the vendor how staff prevent the original and replacement from both appearing as active preparation instructions. If the system cannot connect them, decide what written or screen-based reference staff will use. The fallback may take longer, but it gives the team a defined path instead of an improvised one.
Permissions matter too. Decide who can remove an item, approve an adjustment or issue a refund, and who takes over when that person is unavailable. Include those steps in shift training. A change process that works only when the manager is standing beside the kiosk may not meet your service needs.
Compare the handoff with the rest of your setup, including your restaurant POS system and restaurant management software. Ask vendors to show the complete workflow on the proposed configuration, including any separate devices or services involved. If you are also weighing the broader cost of a kiosk, use the kiosk break-even guide alongside your installed-cost quote.
Next step: Take the worksheet to your vendor demonstration and compare your requirements with Fleksa’s kiosk offering. Ask Fleksa to show how your proposed setup handles a submitted-order change and confirm current availability before choosing a workflow.
Frequently asked questions
Can a guest change a kiosk order after paying?
That depends on the system and the restaurant’s policy. Staff should find the submitted order, check preparation status and determine whether an edit, adjustment or replacement order is available.
Who should notify the kitchen about a change?
Assign one employee to own the request. That employee should make sure every affected station receives the revised instruction and confirms it, particularly if the system does not provide a dependable acknowledgment.
What if the revised order costs less?
Calculate the difference using the actual payment setup and follow the restaurant’s approved refund or adjustment process. Ask the vendor how the original payment and the adjustment appear together in staff records.
