A kitchen display should make a remake unmistakable to the cook while preserving the financial record of the original sale. Before choosing a system, ask the vendor to show exactly how a replacement is identified, who can authorize it, and how it appears in both the kitchen queue and sales records.
The label alone is not enough. A ticket can say “remake” and still be counted incorrectly in a report. Equally, a replacement can reach the right cook but never reach the guest. Test the kitchen handoff and the financial record as separate steps.
Start with the path from complaint to replacement
A remake replaces food that has already been prepared. That differs from modifying an item before it is made. The kitchen needs to know that the first dish existed, what to prepare now, and why the replacement should not be treated as another paid order.
Start the workflow with information a staff member can actually observe: the original order, the item in question, the guest’s reported problem, and the person requesting a replacement. A server might report that a guest received the wrong side; an expo might spot the mistake before the plate leaves the pass. Those are different sources, but both should lead to a clear authorization step.
Do not assume the screen can infer the reason from a modifier or a second item. Ask what staff must enter, whether the original order can be referenced, and what the cook sees without opening another screen. The replacement should specify the item and preparation instructions. The reason should be useful enough to prevent the same mistake, without burying the action under a long note.
Agree on roles before the demo. For example, a server records the complaint, a shift manager authorizes the remake, a cook prepares it, and the expo checks the replacement against the request. The manager then checks the financial record. In a small restaurant, one person may hold several roles, but each check still needs an owner.
When comparing displays, review how ordinary items, quantities and modifiers are presented. Fleksa’s order management documentation is a starting point for the standard kitchen workflow; ask for a separate demonstration of your remake process.
Compare a flagged remake with a new ticket
Two approaches are worth testing. One is a replacement linked to or clearly flagged against the original order. The other is a separate kitchen ticket with instructions identifying it as a remake. Either could work operationally, but only if staff can recognize the replacement and the financial record matches what actually happened.
Use the following hypothetical example as a decision worksheet. A guest paid $18 for one dish. The wrong side was served, and the manager authorizes one replacement at no additional charge. Assume the original $18 sale remains in place and there is no refund. The restaurant prepares two dishes in total but completes one paid sale.
| Check | Flagged remake outcome | Separate ticket outcome |
|---|---|---|
| Cook’s view | One replacement is visibly marked as a remake, with the corrected side. | A second ticket shows the corrected side and clearly says it is a remake. |
| Expo handoff | Expo can identify the replacement and match it to the waiting guest. | Expo can identify the separate ticket as a replacement, not another guest’s order. |
| Sales record | Original sale remains $18; the replacement adds $0 in sales. | Original sale remains $18; the replacement adds $0 in sales. |
| Decision | Suitable if the label, authorization and reporting checks all work. | Suitable if the separate ticket is equally clear and does not add a sale. |
The table describes acceptable outcomes, not promised vendor behavior. Compare them against the same demonstration. If the separate ticket looks like an ordinary new order, the cook or expo may prepare or hand off the wrong item. If either method adds another $18 sale, the record would show $36 against the guest’s actual $18 purchase. That result changes the choice: the workflow needs correction before it is suitable.
The example compares recorded sales, not profit or processing fees. It excludes fixed costs, variable costs such as ingredients and labor, and exception costs such as a refund or waste disposal. Those costs may matter when you review remakes, but they are not calculated here. A $0 replacement sale also does not mean the replacement is free to produce.
Ask whether a manager can later find the original transaction and understand the replacement. If the answer requires a handwritten note or a separate log, decide who maintains it and whether the extra step is reliable during a rush.
Test the failure before it reaches the guest
In the demonstration, have the vendor show what happens when the remake is entered as an ordinary new ticket by mistake. The person taking the complaint should not simply send a second dish and hope someone notices. The shift manager authorizes preparation; the expo or cook checks that the ticket identifies the replacement; and the manager checks the financial record.
Use a vendor-supported training environment for this simulation. Set it up so no real card payment, guest message or courier dispatch can occur. Ask the vendor to show the records before and after the correction. Do not assume that every system can recall, reroute or cancel a ticket in the same way.
The failure to look for is a misleading result: a second ticket that looks like a new paid order, an extra sale in reporting, or a replacement that the expo cannot connect to the waiting guest. The staff member who detects it should stop the handoff and alert the manager. The manager should use the vendor’s demonstrated correction procedure, then recheck both the kitchen queue and the financial record.
Ask the vendor these questions while the mistake is visible:
- Can the cook tell which item to make now and that it is a replacement?
- Who can authorize or enter the remake, and how is that authorization recorded?
- What happens if the wrong ticket reaches a station or the expo?
- How is an accidental extra charge prevented or corrected, and who checks it?
- Can staff identify the original order without exposing unnecessary guest details on the kitchen screen?
If the vendor’s answer depends on a particular setup, station arrangement or staff permission, include that condition in your buying notes. Also ask about device requirements and any additional screen charges in a written quote. A workable process that needs an extra device or repeated manual entry may still be acceptable, but you should know what it requires.
Set separate handoff and reporting acceptance criteria
Give every vendor the same scenario and assign someone on your team to mark each result. A pass requires a clear result in both the kitchen and the record; success in one does not make up for failure in the other.
- Request and authorization: The server enters the problem and the shift manager authorizes one replacement. Pass if the vendor shows who is responsible and the cook receives an actionable request. Owner for exceptions: shift manager.
- Kitchen identification: The cook sees the replacement item, corrected side and remake identification. Pass if it cannot reasonably be mistaken for an ordinary new paid order. Owner for exceptions: kitchen lead.
- Expo handoff: The expo identifies the completed replacement and matches it to the waiting guest. Pass if the handoff is clear without relying on an undocumented verbal reminder. Owner for exceptions: expo.
- Financial record: The manager checks the original sale and replacement. Pass if the record reflects the agreed $18 sale and $0 additional sale, with no unintended second charge. Owner for exceptions: shift manager.
- Mistake and correction: Staff identify an ordinary ticket entered in error and follow the demonstrated correction procedure. Pass if the manager can confirm that both the kitchen view and financial record are correct afterward. Owner for exceptions: shift manager.
Record a fail when the vendor cannot demonstrate a required step, when staff must guess which dish is a remake, or when the financial result is wrong. Ask for the exact configuration and any manual steps needed to address the gap. Then repeat the simulation; do not treat a verbal promise as a passed check.
After a successful simulation and staff practice, consider a supervised service pilot with the manager watching real handoffs and reviewing records. That is different from the practice scenario: real service has real guests and transactions. Keep the existing escalation process available and stop to resolve any unclear replacement.
Compare your requirements with Fleksa’s kitchen display system and restaurant POS system. Bring this checklist to a demonstration and confirm current support for your proposed remake workflow before choosing it.
Frequently asked questions
Is a remake the same as an item modification?
No. A modification changes an item’s instructions; a remake replaces food already prepared. Your staff need to know which situation they are handling because the kitchen action and financial checks may differ.
Should a remake always appear on a separate ticket?
Not necessarily. A flagged replacement or a separate ticket can be workable if the cook and expo can identify it and the financial record stays accurate. Compare both with the same demonstration.
Who should check that a remake did not become another sale?
Assign a named role, such as the shift manager, to review the original transaction and replacement record. The cook or expo should check the kitchen handoff separately.
