Use ingredient-level production counts alongside order tickets when several menu items draw on the same components and cooks need a reliable view of what to prepare across those orders. The count can guide a station's workload; the ticket still tells the kitchen which guest needs each finished item and how it must be served.
The extra view is worth considering when shared components create repeated mental math, missed prep or confusion between stations. It is less useful when recipes change often, staff cannot keep the count current, or the screen shows a total without making clear what is still needed. Before buying, ask a vendor to demonstrate the exact workflow with your menu and your team's language.
Map shared components before comparing screens
An all-day total might tell a cook that five bowls have been ordered. An ingredient production count answers a different question: how many portions of a component are needed across the orders currently being prepared? That distinction matters when a bowl and a wrap both use the same chicken.
Start with two items that genuinely share work at one station. Write down the standard component quantity for each, then identify the changes guests can make. A count is only as useful as the recipe and modifier rules behind it. If a cook must guess whether an extra portion is included, the number can create more work than it saves.
The following worksheet is hypothetical. Assume a bowl uses two chicken portions and one sauce portion; a wrap uses one chicken portion and one sauce portion. Three bowls and two wraps are active. One bowl has a no-sauce modifier. For this exercise, a portion is a consistent kitchen prep unit, not a weight or a promise about serving size.
| Active demand | Chicken portions | Sauce portions | Ticket detail to retain |
|---|---|---|---|
| 3 bowls | 6 | 2 | One bowl has no sauce |
| 2 wraps | 2 | 2 | Keep each wrap with its order |
| Total before completion | 8 | 4 | Five items across active tickets |
The table shows component demand, not five identical plates. The sauce total already reflects the modifier: three standard bowl portions minus one, plus two for the wraps. A cook can use the chicken total to plan the station's work, but must return to the tickets to know which bowl gets no sauce and which items belong together.
For a second check, ask a cook to calculate the same totals from the tickets without the screen's aggregate. If the two answers differ, stop and find the cause. It might be a recipe quantity, a modifier rule, a canceled item or a different definition of what the count includes.
Decide whether the count earns its screen space
Ingredient counts are most useful when a station repeatedly handles the same component for multiple items and can prepare portions together without losing ticket priority. A grill cook, for example, may need a quick view of chicken portions while the expeditor keeps track of individual bowls and wraps. The benefit is less counting across tickets, not permission to ignore them.
Set a decision boundary before the demonstration. Under the worksheet assumptions, consider the count for service only if staff can see the active demand, the no-sauce change is reflected correctly, cancellations update the demand, and completion does not leave an ambiguous remaining quantity. The team must also be able to find the original ticket details needed to finish and hand off each order.
If the screen can show an initial total but cannot reliably distinguish needed portions from completed portions, do not use it as the station's remaining-work number. You may still evaluate it as an initial demand view if staff understand that limit, but tickets and a separate kitchen process must control the work. If maintaining the recipe rules takes more effort than counting a small number of tickets, individual tickets may be the simpler choice.
Ask who owns recipe and modifier setup, how changes are checked, and what happens when a component is substituted. Include prep cooks and the expeditor in that conversation. A number that looks tidy to a manager must also make sense to the person deciding what goes on the grill.
Test changes without affecting real orders
Use a vendor-supported training environment for the checks below. Confirm in advance that the simulation cannot charge a card, send a guest message or dispatch a courier. No real payment or guest contact is needed. Ask the vendor to show the screen behavior rather than assuming every kitchen display handles these changes in the same way.
- Enter the starting orders. Create the hypothetical three bowls and two wraps, including one bowl with no sauce. Check for eight chicken portions and four sauce portions. Open the relevant ticket and verify that the no-sauce instruction remains visible.
- Cancel one standard wrap. The remaining demand should be seven chicken portions and three sauce portions, assuming nothing has been completed. Check how the cancellation reaches the station and how staff can tell the wrap is no longer needed.
- Record partial completion. From that remaining demand, assume three chicken portions are prepared and recorded as complete, with no sauce portions completed. A view labeled remaining should then show four chicken portions and three sauce portions. Ask whether the system can record completion at that level and, if so, how staff do it.
- Inspect the ticket connection. Find the bowl with no sauce and the orders still waiting for components. Ask how a cook or expeditor identifies which portions belong to which ticket and what happens if a mistake is discovered after a completion action.
The arithmetic sets the acceptance target; it does not establish that any particular product provides these actions. If a screen displays seven chicken portions after the cancellation but does not subtract the three completed portions, ask whether it is showing total active demand rather than remaining work. That can be a valid definition, but staff need a clear label and a reliable way to track what is left.
Also ask what happens when a modifier adds a component, when an item is removed from a larger order, and when an order arrives while a cook is recording completion. Have the vendor explain which actions require a manager or a return to the order system. Do not assume a screen can recall or reroute a ticket unless the workflow is demonstrated for your setup.
Keep order identity at the handoff
A component count combines demand; it does not identify the guest, order type, promised timing or complete set of items on a ticket. Before plating, the kitchen still needs the individual instructions. At handoff, someone must match the finished items to the right order and check any special handling.
Decide who performs those checks. A station cook might prepare shared components from the aggregate while an expeditor uses tickets to assemble and verify orders. In a smaller kitchen, one person may do both. Either way, agree on when the team moves from the count back to the ticket: before applying modifiers, before marking an item complete, and before handoff are useful points to examine.
Fleksa's kitchen display presents order information including item names, quantities and modifiers. Its kitchen display system also describes held future orders and configurable timing and color indications. Ask to see how your own order flow appears and whether the ingredient-count workflow you need is available in your setup; do not treat a menu-item quantity as an ingredient count.
If different stations handle chicken, sauce and final assembly, map where each ticket needs to appear before deciding on screen placement. The guide to routing kitchen tickets by preparation station can help frame those questions. Check how menu maintenance fits your broader restaurant management workflow, too: a recipe change that never reaches the production rule can make a previously useful total misleading.
Move from simulation to a supervised service pilot
After the training checks, choose a limited live service period with a manager and station lead watching. Explain which screen is authoritative for orders, who records completion and how staff should report a mismatch. Keep the normal ticket-based process available; do not rely on the aggregate alone while the team learns it.
During the pilot, note each mismatch and its cause: an incorrect recipe, an unclear modifier, a late cancellation or a missed completion action require different fixes. Review the workload as well as the arithmetic. If cooks spend more time correcting the count than it saves, narrow the workflow to a smaller set of shared components or stay with tickets.
Before committing, ask for a written quote that separates screen and setup charges from ongoing software and support charges, and clarify any costs for additional devices or changes. Compare the totals against the work your team expects the count to remove, without assuming a particular saving.
Bring the two-item worksheet and your actual menu rules to a conversation with Fleksa. Discuss your requirements and ask for a demonstration of the workflow and current product fit before scheduling a supervised pilot.
Frequently asked questions
Are ingredient counts the same as all-day item totals?
No. An item total counts menu items, such as bowls sold. An ingredient production count combines component quantities across items and needs a clear definition of which orders and completion states it includes.
Can a kitchen use the aggregate count instead of tickets?
No. The aggregate can guide shared preparation, but tickets preserve order identity, modifiers and the information needed to assemble and hand off each order correctly.
What should a kitchen do if a cancellation does not update the count?
Use the established ticket-based process to manage the affected work and ask the vendor how cancellations are communicated and reflected. Do not treat an outdated aggregate as the remaining production requirement.
