How do you handle a tag that fails during a run?
Separate it physically and immediately, into a container it cannot leave by accident. The single rule that prevents most production disasters is that a suspect tag never returns to the good pile, because nothing about its appearance will ever reveal what it is.
The one rule
A tag that failed, hesitated, or that you are not certain about goes into a separate container immediately. Not to the side of the table, not under your hand, not back on the pile to deal with later.
The reason is that tags carry no visible state. A locked tag, a half written tag and a perfect tag are indistinguishable, so a suspect tag that rejoins the batch is untraceable and will be shipped.
This rule costs nothing and prevents the failure mode that actually hurts, which is a customer receiving something that does not work.
Triage: recoverable or not
Once the run is done, read each rejected tag and sort it.
Recoverable: a partial write, a formatting problem, a tag that simply was not presented long enough. These read as unformatted, unknown or with truncated content, and they can be reformatted and rewritten.
Not recoverable: a locked tag, whatever it holds. It cannot be rewritten, reformatted or erased, so there is nothing to do with it.
Uncertain: a tag with a damaged antenna from creasing during handling, which reads intermittently. Treat these as not recoverable, because an intermittent tag in a shipment is worse than a dead one.
Reworking recoverable tags
Format, write, verify, and keep them in a separate batch until they have all passed.
Do not merge reworked tags into the main pile until they are verified, and consider not merging them at all. Keeping a reworked batch identifiable means that if a problem surfaces later you know which tags to suspect.
If the same tags fail a second time, stop. A tag that resists two attempts is telling you something about itself rather than about your technique, and the cost of a third attempt exceeds the tag.
Disposing of the rest
Destroy them rather than storing them. A drawer of unusable tags will eventually be mistaken for stock by somebody, and the whole discipline collapses at that moment.
Cutting through the antenna is enough and takes a second. It also guarantees that a tag which held content you would rather not distribute is genuinely finished.
Record the count. A rejection rate that jumps between runs is a signal about a supplier, an operator or a tool, and you can only see it if the numbers exist.
The disaster this prevents
A locked tag returned to the good pile, applied to a product, shipped, and discovered by a customer whose card does nothing. Every step of that chain is invisible, and it starts with one tag put down in the wrong place.
Frequently asked questions
Can a failed tag always be recovered?
No. Partial writes and formatting problems usually recover, and a locked tag never does. Damaged antennas are physically broken rather than mis programmed.
Should I keep failed tags for testing?
A few, deliberately marked and stored away from stock, are useful for testing failure handling. A drawerful is a hazard waiting to be mistaken for inventory.
How do I mark a suspect tag?
A separate container is more reliable than a mark, since a mark can be missed and a container cannot. If tags must be marked, do it in a way that survives handling.
What rejection rate should worry me?
A rate noticeably above your own baseline, whatever that baseline is. The absolute number matters less than the change, which is why recording it per run is worth the effort.