How do you verify a batch was written correctly?
Read the tags back and confirm the record type and the content, not merely that the phone reacted. Verify every tag for anything leaving your hands, and sample from the end of the run for internal deployments, since failures cluster towards the end.
What verifying means
Not that the phone made a sound. A tag that responds is a tag that exists, which was never in doubt.
Verification means reading the content back and confirming three things: that there is exactly the expected number of records, that the record type is what you intended, and that the content is complete rather than truncated.
The record type is the one people omit, and it is the one that produces a tag which reads perfectly and does nothing when tapped.
Everything or a sample
Verify every tag for anything that leaves your hands. Cards given to customers, tags shipped to a client, anything you will not see again.
The arithmetic is simple. Verification costs about a second per tag. A customer holding a card that does nothing costs a support conversation, a replacement, and some amount of their opinion of you.
Sample for internal deployments where you can revisit a tag cheaply, and where the consequence of a bad one is an inconvenience rather than an embarrassment.
Sample from the end
If you sample, take the sample from the end of the run rather than the top of the pile.
Failures cluster late. Operator technique degrades as speed increases, tags are presented for less time, and the last hundred are consistently worse than the first hundred.
A sample from the top of a pile is a sample of the careful part of the run, which is precisely the part that did not need checking.
Recording the result
Note the count verified and the count rejected, per batch, with the date.
A run with a rejection rate far above your normal is telling you something: a substituted chip, a new operator, a different surface, a tool update. Without a baseline you cannot notice that, and the information arrives only when a customer complains.
Over several runs the numbers also give you something to quote. Knowing your real yield turns a guess about how many spare tags to order into a calculation.
Frequently asked questions
Is reading a tag enough to verify it?
Only if you look at what comes back. Confirming that a tag responded proves nothing about its content, its record type or whether the write completed.
How long does verification add to a run?
Roughly a second per tag, which is small next to the handling time. For a run of several hundred it is a matter of minutes rather than a second pass of comparable length.
Should I verify after locking?
Verify before locking, always, since locking a bad tag makes it permanent. Verifying again after locking confirms the lock took, which is a different check.
What rejection rate is normal?
It depends on the tags, the operator and the method, so the useful figure is your own baseline rather than a published number. Record it and watch for changes.