When a dish is canceled or modified, the station should see the new demand for each affected component without treating prepared food as if it disappeared. Subtract only what the original dish required, add any new requirements, and flag prepared items that may no longer be needed. Staff then decide what to do with the food.
The buying question is whether your kitchen display makes that change clear enough to act on during service. Ask vendors to demonstrate both the updated count and the sequence of events behind it. A total alone may not tell a cook whether to stop making a component or whether an item is already sitting at the pass.
Separate demand from food already prepared
Start with three different numbers. Dish demand is the number of active dishes guests still want. Component demand is the total quantity of an ingredient or preparation those dishes require. Prepared quantity is what staff have already made or set aside.
For example, three active dishes might need three portions of rice between them. If two portions are ready and suitable for those dishes, the station has one more portion to prepare. If a dish is canceled, demand may fall to two while the two prepared portions remain. The kitchen should not make another portion, but it should not report that a prepared portion vanished either.
A useful working calculation is active component demand minus suitable prepared portions, with the remaining queue never below zero. Any prepared quantity above current demand is a potential surplus, not a negative cooking task. This calculation depends on the station knowing what is actually ready and whether those portions can serve the remaining dishes. A display cannot settle that physical question just by changing a number.
Prepared food may be in a pan, plated, held for a particular ticket, or unsuitable for another dish. Your team needs a procedure for identifying it and deciding whether it can be used. Follow your restaurant's food-handling rules; a component counter is not an inventory or food-safety record.
Consider where staff need to see the change. The cook making the shared component may need a prominent stop or adjustment notice. The expeditor may need to know which dish changed. A server may need to confirm a modification. Those are different actions, even when they come from one order update. If work crosses several stations, the guide to routing kitchen tickets by preparation station can help you map who receives each part.
Follow one cancellation and one modification
The following is a hypothetical sequence, not a claim about any product. Three active dishes require one rice portion each. Two of those dishes also require one sauce portion each. The station has prepared two suitable rice portions and one suitable sauce portion. Assume the prepared portions can be assigned to any remaining dish that needs them, and that staff have not started the remaining portions.
First, one rice-and-sauce dish is canceled. Then the other rice-and-sauce dish is changed to rice without sauce. The third dish remains rice without sauce throughout. The table tracks total active demand, not an inventory balance. A demand reduction happens only once for each accepted change.
| Stage | Rice: demand / prepared | Sauce: demand / prepared | Station action |
|---|---|---|---|
| Before either change | 3 / 2 | 2 / 1 | Queue one rice and one sauce portion. |
| After cancellation | 2 / 2 | 1 / 1 | Remove one rice and one sauce from demand. No further portions are needed. |
| After modification | 2 / 2 | 0 / 1 | Keep rice demand unchanged. Remove one sauce from demand; flag the prepared sauce for a staff decision. |
Read each cell as two separate quantities: what active dishes need and what is already prepared. After the cancellation, the prepared food exactly covers the remaining demand under the example's assignment assumption. After the modification, both rice portions are still needed, but the one prepared sauce portion is surplus to these dishes.
Check the canceled dish
The canceled dish originally contributed one rice and one sauce to the shared totals. Reversing those contributions takes rice demand from three to two and sauce demand from two to one. The previously queued rice and sauce are no longer needed. Prepared quantities stay at two and one; the cancellation did not unmake them.
Pass: The display or its history identifies the canceled dish, updates both affected component totals once, and gives the relevant station a clear notice. The resulting preparation queue is zero for each component under the stated assumptions.
Fail: The cancellation is applied twice, a count becomes negative, or the station sees no usable indication that the queued work should stop. Also treat it as a failure for your workflow if the screen changes silently while cooks have no reliable way to notice it.
A duplicate update is different from a second legitimate cancellation. Ask how the system distinguishes the same event arriving twice from two separate guest requests. Staff should not have to guess whether tapping an alert again will subtract another portion.
Check the changed dish
The remaining rice-and-sauce dish still needs rice. Its modification removes only the sauce requirement, taking sauce demand from one to zero. Rice demand stays at two. Subtracting the entire old dish without adding back its unchanged rice would undercount the work still needed.
The prepared sauce remains physically present. A cook or expeditor needs to identify it and decide whether it can be used elsewhere under the restaurant's procedures. The example does not assume another order exists or that the sauce is automatically reusable. If the sauce was already on the changed dish, staff may need a different correction than if it were still in a separate container.
Pass: The modification removes one sauce, leaves rice unchanged, and makes the surplus visible to the person responsible. Reopening or acknowledging the change does not remove a second sauce.
Fail: Sauce demand drops below zero, rice is removed from the active requirement, or the prepared sauce is silently treated as unprepared. A screen that shows the final total but gives no indication of the changed dish may also be inadequate if your cooks need that context.
Set the staff response before comparing screens
Before a demo, write down what should happen at each point in your own kitchen. A component may be untouched, in progress, prepared, plated, or sent to the guest. The same cancellation can require a different response at each stage. A lower count is useful, but it does not by itself stop a cook or recover a plated item.
- Not started: The station needs to see that the portion is no longer required before starting it.
- In progress: The cook needs an actionable notice and a way to decide whether to stop or complete the preparation.
- Prepared or plated: Someone must locate the food and decide what happens next. A counter should not erase the physical portion.
- Already sent: The team needs an agreed communication path; changing a kitchen total cannot bring a dish back.
Decide who acknowledges a change and what acknowledgement means. It might mean only that a cook has seen the update, not that the food has been handled. If the action still needs an expeditor's decision, make that responsibility explicit. Ask whether an alert stays visible until acknowledged and whether another station can see that it was handled.
Also decide how the front of house communicates urgent changes. If a server changes an order while a cook is plating, the screen update and a direct verbal handoff may both matter. Your process should cover an alert missed during a rush, not rely on everyone watching a display continuously.
For components used by multiple dishes, agree on the unit of count. One sauce portion per dish is straightforward; a batch, half portion, or modifier with a different serving size needs an explicit rule. Ask how the system handles your actual menu rather than assuming every modifier changes a shared count correctly.
Ask vendors to demonstrate the change history
Use the same simulated sequence for every vendor. Set up the three dishes and their component requirements, record the starting demand and prepared quantities, then make the cancellation and modification in order. Ask the demonstrator to show the station view, the individual tickets and the history after each step.
The history should be understandable to a manager investigating a discrepancy: which dish changed, what its old and new requirements were, when the change was recorded, and whether a staff member acknowledged it. Ask what the system records automatically and what staff must enter. If prepared quantities are tracked outside the display, include that handoff in the demonstration rather than assuming the screen knows what has been cooked.
Ask these questions while watching the workflow:
- Can a station see both the affected ticket and the revised shared-component demand?
- How is an unchanged component preserved when another component is removed or replaced?
- What happens if the same cancellation or modification is received or submitted twice?
- Can staff distinguish a notice they have seen from a food-handling action they have completed?
- What can a manager inspect later if a total looks wrong, and can the sequence be understood without relying on a cook's memory?
- How do updates reach each affected station, and what should staff do if a display or connection is unavailable?
Ask for a written description of any setup or extra tools needed to achieve the workflow. A vendor may show ticket quantities and modifiers without offering the shared-component reversal or history your station needs. Those are separate buying requirements.
Fleksa's kitchen display system shows order details including item quantities and modifiers. Ask for a demonstration of the component-count and acknowledgement workflow before deciding whether it fits. Your restaurant POS system and restaurant management software also matter to the handoff: confirm where a change is entered and how it reaches the kitchen.
Turn the worksheet into a safe trial
Run the scenario first in a vendor-supported training environment. Use simulated orders and simulated acknowledgements. Confirm that the exercise cannot charge a card, send a guest message, or dispatch a courier. No real payment, guest communication, or courier dispatch is needed to practice a count change.
Have one person enter changes and another follow the station instructions. Record the expected and actual totals after each event, including the prepared quantities. Repeat the same update to check for double subtraction, then ask the station to explain what it would do with the surplus sauce. This is a simulation, not evidence of how the system performed in a live service.
If the simulation meets your requirements, move to a supervised service pilot with your normal guest and payment procedures. Give staff a named person to contact about unclear updates and a fallback communication method. Review discrepancies after service, including whether the right person saw and acted on each change.
Use the worked table and questions above as your decision worksheet. Compare your requirements with Fleksa's KDS, and ask the team to demonstrate the relevant cancellation and modification workflow before you buy.
Frequently asked questions
Should a cancellation reduce the prepared-food count?
Not automatically as a matter of kitchen logic. It reduces active demand; food already made still exists. Staff need to identify any surplus and decide what to do with it.
What if a modification removes one component but keeps another?
Remove the old requirement that changed and retain the component still needed. Check the revised ticket and shared totals so the unchanged work is not accidentally subtracted.
How can a manager check for a double reversal?
Compare the event history with the original and revised dish requirements. Repeating the same event should not subtract its components again, and active demand should not go below zero.
