Yes, a manager can distinguish original preparation from remakes if the kitchen display system records the remake as a separate event and makes that event available in a usable report or export. A button that sends another ticket to the kitchen is not enough. Before buying, ask the vendor to show how the original item, the additional preparation and the reason appear in the numbers you will review.
The distinction matters because a remake creates work without necessarily creating another sale. If your report only counts orders or tickets, a busy shift can look lighter than it was. If it treats every remake as a new sold item, sales and production counts can become hard to reconcile.
Define what the report needs to count
Start with the original item: a unit ordered for a guest and sent for preparation. An order can contain several item lines, and a line can have a quantity greater than one. For workload purposes, the quantity matters more than the number of lines. Two burgers on one line still mean two burgers to prepare.
A remake event is an additional instruction to prepare an item again. It should be distinguishable from the original instruction and, ideally, traceable back to the item and order involved. A manager may also need to know whether the entire item or only one component was prepared again. Agree on that definition before comparing reports; otherwise, two locations could count the same situation differently.
A reason explains why the extra work happened. Useful categories might include an incorrect modifier, a preparation mistake, a damaged item or a guest request. Choose categories your team can apply consistently. An optional note can add context, but free text alone is difficult to summarize across a week of service.
Also decide who may record or change a reason and whether a manager can identify an entry that was corrected later. A report is less useful when staff can overwrite a remake with no way to understand what changed. Ask the vendor what history, permissions and reason fields are available in your setup.
Use one sample order to expose the difference
The following is a hypothetical evaluation, not a claim about any product. A guest orders two burgers and one salad. Both burgers are prepared, but one has the wrong modifier and must be made again. The salad is prepared once. The restaurant records the reason as an incorrect modifier.
The order contains three original units. The kitchen prepares one additional burger, so the total workload is four full item units: three original preparations plus one remake. The guest ordered three units; the extra burger is not automatically another sold unit. Whether the restaurant charges for any change is a separate transaction question.
Ask the vendor to walk through this case in a supported training environment. First, enter the order and send it to the kitchen. Then record the burger remake using the workflow the restaurant would actually use. Finally, open the manager view and export the relevant records. The simulation must not take a real payment, send a guest message or dispatch a courier.
Watch for the point at which the reason is captured. If the cook can send a replacement but a manager must add the reason elsewhere, that may still work, but it adds a step. Ask what happens when that step is missed. Can the manager find an unclassified remake and correct it without losing the original record?
Use the same scenario for each product you consider. Do not accept a screen showing only that a replacement appeared in the kitchen. The buying question is whether the resulting records let a manager separate the original work from the additional work later.
Compare tickets with units prepared
A ticket count is not a dependable substitute for a preparation count. One ticket may contain several units. A remake might appear on a separate ticket, on an existing ticket or in another record altogether, depending on the workflow. For the sample order, a count of one or two tickets would not by itself establish that four units were prepared.
Ask the vendor to show three distinct measures for the same period: original ordered units, remake units and total units represented as prepared. For the hypothetical order, the expected figures are three, one and four. If the system instead reports items sent for preparation, rather than items confirmed prepared, label the measure that way. A sent instruction does not prove the kitchen completed it.
Station detail can help explain where the extra work fell, but it introduces another counting risk. A burger may pass through more than one station. Adding station-level touches together can overstate the number of complete burgers prepared. Ask whether the report counts whole items, station tasks or both, and how it prevents double counting when totals are combined.
Timing needs a clear definition too. A remake's timestamp may show when it was requested, sent or completed. Those are different events. Before using a report to compare shifts, agree which timestamp places the remake in the reporting period. Consider an original order near the end of one shift and a remake after the next shift begins: the records should make that relationship visible even if the events fall in different periods.
If a product cannot separate these measures in a standard report, ask whether an export or another workflow can do so. Then decide whether the extra manual work is acceptable. A spreadsheet can be useful, but only if the source records contain enough detail to identify the remake and its original item.
Set acceptance criteria and reconcile the export
Before the demonstration, write down the evidence you need and what would count as a pass. The worksheet below uses the sample order as a starting point. Adjust the criteria to match your operation, then apply the same criteria to each vendor.
| Decision point | Evidence to request | Acceptance criterion |
|---|---|---|
| Original work | Order and item records with quantities | The sample shows two original burgers and one original salad, totaling three units. |
| Remake identity | Remake record linked to the original order and item | One additional burger is identifiable as a remake, not another original sale. |
| Reason | Reason field and any correction history available | The incorrect-modifier reason is visible; the manager can identify missing reasons. |
| Workload total | Report definition and item-level export | Three original units plus one remake equals four full-item preparations, without adding station touches as extra items. |
| Review and reconciliation | Export fields, timestamps and report filters | The manager can trace the four-unit total to the sample records and explain the reporting period used. |
The table sets a deliberately specific standard. A vendor may use different field names, but the manager still needs a traceable path from the summary total to the underlying order and remake. Ask to see the actual export format, not just a description of what a dashboard can display.
For reconciliation, compare the original order record with the remake record and the report total. Check the order or item identifiers, quantities, event type, reason and relevant timestamps. Confirm whether canceled entries, corrections or partial remakes appear, and how they affect the total. If a record is excluded from the report, the vendor should be able to explain why.
Then run one additional simulated case that fits your menu: for example, a replacement component rather than a complete meal. Decide in advance whether your workload measure should count it as a full item, a component task or a separate exception. Do not expect a four-unit total from that different case; judge it against the definition you chose.
After the simulation, staff can practice the agreed process during a supervised live service period using normal, authorized restaurant workflows. That is different from the practice scenario: review whether employees consistently record reasons and whether the manager can reconcile actual records. Set a review date and an owner for fixing gaps before relying on the report for staffing decisions.
For context, Fleksa's kitchen display system is linked to restaurant orders and displays item names, quantities and modifiers. Ask how remake events and exports work in your setup. You can also review the restaurant POS system and the guide to routing tickets by preparation station when deciding where the records and workload measures should connect.
Next step: Use the worksheet to compare your requirements with Fleksa. Bring the sample order to a demonstration and confirm the remake workflow, report and export before buying.
Frequently asked questions
Does a separate remake ticket prove a report counts remakes?
No. It shows an instruction reached the kitchen, but the report may count tickets rather than remake units. Ask to see the exported record and how it connects to the original item.
Should a remake be counted as another sale?
Not automatically. A remake is additional preparation work; a sale is a separate measure. Check the order and payment records rather than assuming the kitchen count changes revenue.
What if the report has no remake reason?
Ask whether reasons can be captured and exported elsewhere, and whether missing reasons can be identified. If the team must maintain a separate log, include that work in your buying decision.
