We have been called in to rescue enough RFID deployments to see a pattern. The failures are rarely technical in the way people expect. Here are the five real causes.
1. The tag was chosen from a catalogue
A tag that reads perfectly on a cardboard box reads badly on a metal drum and not at all inside a liquid container. Choosing from a specification sheet without testing on the actual product is the single most common cause of a disappointing read rate.
What to do: insist on a read-rate trial on your own goods, in your own orientation, before you commit to a quantity. Any supplier who resists this is telling you something.
2. The antenna was mounted where it fit, not where it should go
Antenna gain, angle, height and distance decide coverage. Mounting an antenna where there happened to be a free bracket is how you get a portal that reads 90% of a pallet — which sounds good and is useless, because you cannot tell which 10% is missing.
What to do: treat antenna positioning as an engineering step with a documented result, not as installation.
3. Stray reads were never controlled
A reader that picks up tags from the next lane, the next aisle, or the pallet waiting behind produces data that is wrong in a way nobody notices for months. Shielding, power tuning and read filtering are what prevent this.
What to do: test not only that the right tags are read, but that the wrong ones are not.
4. The process did not change
This is the biggest one. A warehouse installs RFID, keeps the paper goods-receipt process running alongside "just in case", and two years later staff still trust the paper. The technology worked; nothing changed.
What to do: decide in advance which manual step is being retired, agree a date, and retire it. If nothing is being retired, the project has no return.
5. Nobody owned the routine
RFID makes counting cheap. Cheap counting only helps if someone actually counts. Deployments where a named person owns "the weekly cycle count" hold their accuracy. Deployments where counting is "available" drift back within a quarter.
What to do: name the owner and put the count in a calendar before go-live, not after.
The pattern
Four of these five are not about hardware. They are about testing before buying, and about changing the process afterwards. The reader is almost never the problem.