A manager can distinguish rejected tickets from completed and canceled orders only if the order records preserve those outcomes separately and the reporting process makes them visible. A screen that shows completed tickets is not enough: ask what happens when the kitchen declines work, where the reason is recorded, and how a manager finds it later.
Make that distinction a buying requirement if rejected work affects guest communication, refunds, staffing decisions, or the accuracy of your daily order count. Use the same small set of simulated orders with each vendor, then compare the report with the source orders.
Decide who needs the answer and when
Start with the manager who closes the shift. That person needs to explain what happened to every order, not just see how many tickets left the kitchen. Assign a second owner for the action itself: typically a kitchen lead records a rejection, while a front-of-house lead handles the guest and any payment follow-up.
Agree on what each status means in your operation. An accepted ticket is work the kitchen has agreed to prepare. A completed ticket is accepted work marked finished under your chosen definition. A rejected ticket is work the kitchen declines before accepting it. A canceled order is stopped after it was placed; for this worksheet, cancellation happens after acceptance. Your vendor may use different labels or permit different transitions, so ask for its definitions before comparing reports.
That distinction matters during a rush. If an ingredient runs out, a manager may need to spot repeated rejections and update the menu or alert the order-taking team. A canceled order may instead need a different follow-up. If both appear simply as closed, the manager has extra work to determine what happened.
Decide how quickly the answer is needed. A small counter-service restaurant may be comfortable reviewing exceptions at closing. A busy operation with several order channels may need a manager to see them during service. Also decide whether a ticket, an item, or the whole order is the unit being reported. One order can send work to more than one station, so ticket totals do not necessarily equal order totals.
Map the status trail before comparing reports
The following worksheet is hypothetical. Each source order creates one kitchen ticket, and each has one final outcome. The accepted count is a transition count, not a final-outcome count. The kitchen lead owns acceptance, completion, and rejection; the front-of-house lead owns the cancellation.
| Source order | Status trail | Reason or detail | Action owner |
|---|---|---|---|
| 101 | Accepted, completed | Prepared as ordered | Kitchen lead |
| 102 | Accepted, completed | Prepared as ordered | Kitchen lead |
| 103 | Accepted, completed | Prepared as ordered | Kitchen lead |
| 104 | Rejected | Ingredient unavailable | Kitchen lead |
| 105 | Rejected | Reason missing | Kitchen lead |
| 106 | Accepted, canceled | Guest canceled | Front-of-house lead |
The six source orders produce four acceptances, three completions, two rejections, and one cancellation. Do not add all four counts together: the three completed orders and the canceled order were also accepted. The final outcomes do reconcile: three completed plus two rejected plus one canceled equals six.
Order 105 is the important exception. A report could show the right rejection count and still leave the manager unable to explain it. Decide whether your process requires a reason for every rejection, who enters it, and what the manager does if it is missing. A useful report should let the manager identify the specific order, not just see an unexplained total.
For a more complex setup, repeat the exercise with an order that creates tickets at two stations. Ask how the system connects each ticket back to the source order and how a partial rejection appears. Do not count two station tickets as two lost orders without checking what happened to the rest of the order.
Compare approaches and their operating costs
Use the worksheet to compare three practical approaches. The right choice depends on how often exceptions occur and how much time a manager can spend reconstructing them.
Reported statuses and reasons
Ask whether the product can show rejected, completed, and canceled work separately, retain a rejection reason, and connect each outcome to its source order. Check whether the manager can filter the relevant period and inspect individual records. If those requirements work in the demonstration, staff have less manual information to assemble at closing. The guest still needs a clear response; a report alone does not provide one.
Fleksa offers a kitchen display system linked to restaurant orders. Its public product description includes order type, items, quantities, modifiers, future held orders, and configurable timing and color indications. Ask to see how your proposed setup handles rejection statuses and reasons rather than treating those display details as proof of a rejection report. The order management documentation is a useful starting point for preparing questions.
Square describes kitchen tickets, timers, station routing, and expeditor functions for its KDS. Toast also offers a kitchen display product. For either, ask for the same rejection-and-reconciliation demonstration; those product descriptions alone do not establish how your required report works.
Order history plus a manual exception log
If a product shows order outcomes but does not give you the rejection detail you need, a shift log may fill the gap. Record the order identifier, time, reason, staff owner, and follow-up status. At closing, the manager compares the log with the order history. Set a deadline for filling gaps while the staff involved are still available.
This approach adds staff effort and depends on consistent entries. It may suit a low-volume operation, but a log completed from memory after a busy service can leave missing reasons. Ask who covers the log when the kitchen lead is occupied and how the front-of-house team learns that a guest needs attention.
Change the workflow or keep looking
If the system cannot distinguish an outcome and the team cannot reliably maintain a log, do not assume training will solve the reporting gap. Ask whether a different supported workflow captures the decision at another point, such as in the order record. Demonstrate it end to end. If it still cannot produce the minimum evidence your manager needs, continue comparing products or narrow the requirement deliberately.
Compare written quotes alongside the workflow. List fixed software and equipment charges, variable processing or other usage charges, and exception-related costs such as staff time spent reconciling records. A quoted processing fee alone is not the all-in operating cost. Ask about extra screens, setup, support, and any other charges relevant to your configuration; do not assume they are included. Fleksa's plans page is the starting point for its published pricing, checked November 2026. Confirm the current quote and applicable costs before deciding.
Run a pass-or-fail reconciliation test
Before selection, give each vendor the same worksheet and your definitions. Ask for a vendor-supported training environment. Keep the exercise simulated: it must not trigger a real card payment, guest message, or courier dispatch. If a demonstration cannot safely simulate a step, discuss and document that step instead of creating a live transaction.
- Set up the source list. Create the six hypothetical orders and record their identifiers. Confirm that each creates one ticket for this first test.
- Apply the actions. Accept and complete 101–103, reject 104 with the stated reason, reject 105 without a reason if the workflow permits it, and accept then cancel 106. If a required reason prevents the action on 105, record that behavior rather than forcing a different outcome.
- Inspect the results. Ask the demonstrator to show the relevant order records and report for the test period. Record the displayed labels, counts, reasons, and links between tickets and source orders.
- Reconcile final outcomes. Account for all six source orders once: three completed, two rejected, and one canceled, provided all six actions could be performed as specified. Separately check the four acceptance transitions. Investigate any missing, duplicated, or differently classified record.
- Check the reasons. Order 104 should show the ingredient reason somewhere the manager can retrieve it. Order 105 should either be flagged as missing a reason or be prevented from being rejected without one. A correct total with an invisible missing reason fails this requirement.
Keep a simple record of what was shown, including any steps that required a separate screen or manual log. Ask whether the same view is available to the shift manager's intended role and whether it covers all of your intended order sources. If the vendor uses different statuses, map them to your definitions and check that the mapping preserves the distinction you need.
For the hypothetical decision, suppose a demonstration accounts for all six orders but gives the manager no way to identify the missing reason on 105. The count passes; the reason check fails. If the restaurant requires every rejection reason in a retrievable record, that workflow does not meet the requirement. The manager can ask for another supported method, accept a named manual-log fallback, or keep looking. A fallback is only credible if someone owns it and checks it against source orders each shift.
After a satisfactory simulation, train the team in the supported environment and then observe a supervised live service period using normal operating procedures. Review real exceptions with the responsible staff afterward. A live pilot is a separate operational step, not a reason to send practice orders to guests or couriers.
Make the next decision
Bring your status definitions, worksheet, and minimum pass criteria to a demonstration. Compare the result with your current process, including the time needed to close gaps. Ask Fleksa to demonstrate the applicable kitchen display and order workflow for your setup.
Frequently asked questions
Is an accepted ticket the same as a completed ticket?
No. Acceptance means the kitchen has agreed to take the work under the worksheet's definition. Completion is a later outcome. Confirm how each vendor defines and records both events.
Can a rejection count replace a rejection reason?
No. A count shows how often an outcome occurred, but it does not explain why. If reasons matter to your operation, require a retrievable reason or a reliable manual fallback for each rejected ticket.
What if an order creates tickets at several stations?
Ask how each station ticket connects to the source order and how partial rejection is recorded. Reconcile at both the ticket and order level so multiple tickets are not mistaken for multiple orders.
