When an RFID warehouse system underperforms: diagnosing the cause

01 / FIELD NOTE

Keep the decision tied to the operating context.

An RFID deployment that disappoints usually keeps working. The readers are installed, the tags respond, the network is up, and the warehouse system is the one that ran the operation before. What fails is the translation between them, and that failure is easy to misattribute to the devices because the devices are the visible part.

Frequency is the first thing to check and the easiest to get wrong, because the choice is usually made once, early, and never revisited. Different bands behave differently: the physics that suit a dock door do not suit a long-range or a dense-reader application, and a system specified for one condition deployed into another will work well enough to be believed and poorly enough to be useless. The question is not which band is the stronger choice but which suits this read.

Antenna placement is the second and it is a geometry problem rather than a device problem. Where the antenna is, which way it faces and how high it is mounted determine what the field actually covers — and the field does not respect the boundaries drawn on a plan. A portal that reads the neighbouring dock as well as its own, or that misses the bottom of a pallet, is a placement decision rather than a fault.

Material is the third and it is a property of the goods rather than of the equipment. Metal reflects, liquid absorbs, and both change how a tag behaves in ways that vary with distance and orientation. A tag chosen for a good read on plain packaging may behave differently against a steel shelf or inside a full drum, and the remedy is a different tag or a different mounting rather than more power.

Interference is the fourth and it is the one that appears after go-live. Other readers, other radio equipment, and the density of the installation itself all affect performance, and a site that worked during commissioning can degrade as more readers are added or as neighbouring operations change. A dense-reader environment needs coordination between readers rather than each one operating at maximum.

The integration layer is the fifth and the most commonly missing. Readers produce observations; a warehouse system needs business events. Without a layer that filters duplicates, applies time windows and maps reads to specific process steps, the system receives noise attributed to the wrong events. The symptom that surfaces first is usually the same pallet appearing to be processed more than once, which is the reader doing its job.

Reader power is the sixth, and the instinct to turn it up is usually wrong. More power extends the zone, which is useful until it reaches stock that should not be counted yet, or a neighbouring dock, or the previous pallet still in the staging area. Coverage problems are more often solved by a better-placed antenna at lower power than by the same antenna turned up.

Tag application is the seventh, and it is the one most often delegated. A tag applied by habit — against metal, under a liquid, on a curved surface, facing away from the reader in storage — will read poorly for its entire life, and the failure will be attributed to the technology. A placement standard, verified on a sample before a wave of tags is applied, prevents a class of problem that is expensive to correct afterwards.

Beyond those, the diagnosis worth applying is whether the process changed at all. If capture became automatic but the procedure still requires an operator to confirm each item, the benefit was never realised and the manual work remains. A deployment that has added hardware without removing a step has added cost, and no amount of tuning will produce the result the business was expecting.

Trust is the outcome that decides whether any of this survives. Once supervisors believe the data is inconsistent, they reintroduce the checks the system was meant to replace — a recount, a spreadsheet, an extra confirmation. The system is still running and still costing what it cost, and the operation has reverted to the one it had before. That is a failure mode in its own right rather than a symptom of the others.

Where a system is already installed and underperforming, the useful sequence is to measure before changing anything. What is the read rate at each point, against a known load? Which tags are missed, and where are they in the load? What does the exception queue look like, and who clears it? Those answers localise the problem to frequency, placement, material, interference, integration or process, and they prevent a programme of changes that addresses none of them.

The questions worth answering before a new deployment are therefore not about hardware. What does each tag represent in the workflow. At what level will tagging happen. How will duplicate reads be filtered. What happens when a tag cannot be read or an unexpected item appears. Which single process will be piloted first, and what will be measured. A project that can answer those has designed the system; one that cannot has bought readers.