Staff can learn about a marketplace order change only if the change reaches a screen, ticket, or notification someone is watching. An integration may send an update to the POS or kitchen, but you should not assume that every marketplace change replaces the original ticket or alerts the cook. Confirm the behavior for each channel, location, and POS combination.
Until that behavior is verified, give one person responsibility for watching marketplace updates and passing changes to the kitchen. The important question is not just whether a change arrives. It is whether the person preparing the food sees the right instruction in time.
Map where changes start and where staff might see them
Begin with the actual order channels used at each restaurant. A location may receive marketplace orders through a tablet, a POS connection, or another order-management tool. The kitchen might work from a printed ticket, a kitchen display, or both. Write down the path from the original order to the person making it.
For each marketplace and location, ask:
- Can a guest, marketplace support agent, or restaurant employee request a change after acceptance? Which changes are allowed?
- Does the request appear in the marketplace interface, the POS, the kitchen display, a printed ticket, or more than one place?
- Who is expected to watch that place during a busy shift?
- Does the answer change once preparation has started or a courier has been assigned?
Keep cancellations separate from item changes. A canceled order can still be cooking, while a changed order may need only one item remade. Also separate a request to change an order from a change that the marketplace has actually accepted. Staff need to know which one they are looking at before acting.
Use your list when reviewing restaurant integrations. Fleksa's directory distinguishes live connections from those available on request. Availability and setup can differ by location, so check the exact combination rather than treating a channel name as proof that every update will flow through it.
Find out what happens to the original order
Ask the integration and POS providers to walk through a specific change, not just an ordinary new order. Use the same marketplace, location, POS, and kitchen setup that your staff would use. Have them show where the original instruction appears and where the revised instruction appears.
There are several possible handoffs to investigate. An update might replace information on an existing order, add a separate message or ticket, or require a cancellation and a new order. It might instead require someone to make a manual correction. Ask which actions the channel permits and which ones the integration actually carries through.
A replacement is useful only if the kitchen sees it after work has begun. A supplemental ticket is useful only if staff can match it to the original and avoid preparing both versions. A cancellation needs a clear stop instruction; removing an order from one screen does not necessarily remove a printed ticket from the line.
For each supported action, ask the provider to demonstrate:
- How staff identify the original order and distinguish the latest version.
- Whether an item, modifier, quantity, total, or cancellation is shown differently after an update.
- What appears on each screen and printer, including any alert that requires acknowledgment.
- What staff must do manually if an update does not reach the kitchen.
- What happens when the marketplace allows a request that the connected POS cannot apply.
Do not rely on color or a sound alone as the handoff. A busy kitchen can miss either. Ask whether the update remains visible until someone checks it, and decide who will check. If the answer is a separate marketplace tablet, put that check into the shift routine rather than assuming the POS will cover it.
If you are deciding between a POS connection and an intermediary, the related buying guide can help frame that broader choice. For this decision, concentrate on the changed-order path and the manual work left over.
Build an order change handoff matrix
The following is a hypothetical example for one location. Its marketplace and POS behavior are questions to resolve, not claims about any provider. The restaurant receives an order for two bowls; the guest later requests that one bowl have no onions. The original ticket has already reached the kitchen.
| Handoff point | Question or risk | Owner | Next decision |
|---|---|---|---|
| Marketplace request | Is the no-onion request accepted, and where does it appear? | Shift lead | Confirm the accepted instruction before directing a change. |
| POS order | Does the modifier update the original order or appear separately? | Order station employee | Match the update to the original order; flag a mismatch to the lead. |
| Kitchen | Has the affected bowl been started, and can the cook see the revision? | Kitchen lead | Stop, adjust, or remake the affected bowl as appropriate. |
| Packout | Does the packed order match the latest accepted instruction? | Expo | Hold the order if the instruction remains unresolved. |
The matrix follows one instruction from request to packout. It does not assume the marketplace will accept the change or that the POS will display it. If either point is unresolved, the shift lead owns the next decision rather than letting each station guess.
Add a row for cancellation and another for any common quantity or item change. For each row, record the actual screen or printer, the person responsible on that shift, and a backup. A job title helps, but a named on-duty person is better when one employee covers several stations.
Agree on a simple rule for conflicting instructions: pause the affected item, identify the latest accepted order state in the appropriate channel, and have the lead resolve the discrepancy before packout. If the channel provides a way to contact support or respond to a request, identify who can use it. Do not promise the guest a change until staff know it can be accepted and fulfilled.
Walk through a safe simulation, then a live service pilot
Before asking staff to rely on the handoff, run a simulated check with the provider where a safe environment is available. Use a unique test identifier and fictional order details. The simulation must not trigger a real card charge, guest message, or courier dispatch. If the provider cannot isolate those actions, use a tabletop walkthrough with sample screens or tickets instead.
Run the same supported change at two points: before preparation starts and after the original instruction has reached the kitchen. The second case is where a changed screen can leave an outdated paper ticket or an employee working from memory. Include a cancellation if the channel and test environment support it.
For each case, write down the expected result before the walkthrough. Then record what appeared in the marketplace view, POS, and kitchen output; whether staff could match the identifier; and whether items, modifiers, and totals agreed. Note any required manual step and who performed it. Use fictional details, not private guest information.
For example, if the expected result is a visible no-onion instruction on the kitchen output, record whether that instruction actually appears there and how the cook is alerted. A correct POS screen alone does not establish that the kitchen received it. Conversely, an intentionally unsupported change is a documented limit, not a failed promise that every vendor must support that action.
After the safe walkthrough, a live service pilot is an operational trial during an agreed shift, not another simulation. Brief the assigned staff, keep the marketplace view under active watch, and use the manual handoff for any real change. Review the results after service without collecting unnecessary guest details. Do not stage real payments, guest messages, or courier dispatches to manufacture a practice case.
Choose the operating rule before you buy
Compare options by the work they leave your team, not just by the number of channels listed. A setup that shows ordinary orders in one place may still leave changes on a separate tablet. That can be workable if a specific employee can watch it and communicate with the kitchen; it is a weak fit if that responsibility disappears during the rush.
Ask for a written description of supported changes, notification behavior, manual steps, and any location-specific setup. For unresolved cases, name the employee who will watch the source channel, the person who can stop or remake food, and the point at which the order must be held. Include training and shift coverage in the decision.
Bring your channel list and two change cases to a Fleksa demo. Ask how your restaurant POS system and kitchen would receive each update, and confirm availability for your location.
Frequently asked questions
Will a marketplace change automatically update the kitchen ticket?
Do not assume it will. Ask the providers to show what happens for your marketplace, POS, and kitchen setup, including changes made after the original ticket appears.
Who should watch for changed orders?
Assign an on-duty employee to monitor the place where changes arrive, with a backup for busy periods. The kitchen lead should confirm that the preparation instruction reaches the cook.
What if the marketplace and POS show different instructions?
Hold the affected item and have the shift lead identify the latest accepted instruction through the appropriate channel. Tell the kitchen and packout staff the resolution before the order leaves.
