Hardware is rarely the reason an RFID programme fails. In the post-mortems I have read, the readers were installed, the tags were applied, and the portal was detected correctly at 97 %. The project still died — usually in the spreadsheet where someone compared the promised saving with the realised one.

These are the ten pitfalls that account for most of that disappointment, grouped by the stage at which they occur.

Pitfalls 1 and 2: hardware before process, and capacity before demand

The most expensive mistake is the first one, because everything downstream inherits it.

Buying readers before defining the process: a reader is a component, not a solution. Until you can state which business decision the read will trigger — a receipt, an exception, a replenishment signal — any hardware choice is a guess.
Designing for peak volume you do not have: teams buy eight-port readers for a dock door that will never see more than 60 cartons an hour. The extra ports cost money and, worse, encourage antenna layouts that create interference. Size for measured volume plus 50 %, not for a conference slide.

Pitfalls 3 and 4: tagging discipline and the 5 % that poisons everything

Tag application is unglamorous, underfunded and decisive.

Assuming the supplier will tag correctly: source tagging only works when the tag placement is specified in millimetres, the SKU-to-EPC mapping is validated, and a sample is audited on every delivery. Otherwise you inherit a 5 % error rate that quietly consumes the entire labour saving.
Reusing EPCs: leftover and recycled identifiers are the single fastest way to corrupt inventory history. An EPC must be unique for the life of the item and retired when the item is retired, not reassigned to the next box.

Pitfalls 5 and 6: antenna layout and the doorway nobody tested

Physics is unforgiving, and it does not care about the render in the proposal.

Designing the read zone on paper: the drawing shows a clean 2-metre zone at the dock door. Reality includes a metal roller shutter, a forklift that parks in the beam, and a neighbouring aisle. Test with real pallets, real wrap and real traffic for a full shift.
Ignoring the adjacent zone: the most common post-go-live support ticket is phantom reads from the next room. One extra antenna is cheaper than three months of disputed counts.

Pitfalls 7 and 8: integration shortcuts and the missing exception owner

The project usually survives go-live and fails in month two, and this is where.

Writing straight into the ERP: direct database writes or middleware that posts quantities rather than documents bypass the audit trail and break at the first upgrade. Submit documents; let the ERP's logic decide.
Nobody owns the exceptions: every deployment generates 1–5 % of reads that cannot be resolved automatically. If no named person closes them within a defined SLA, they accumulate until the team stops trusting the system — and a system nobody trusts is a system that gets switched off.

Pitfall 9: the pilot that proves nothing

A pilot in one aisle, with one antenna, run by the project team, proves that RFID works. It does not prove that your operation will work with RFID.

A useful pilot has a control group, a baseline measured before tagging, and at least four weeks of run time including one month-end.
It measures the six numbers that matter: read rate, duplicate ratio, unknown-tag rate, latency, adjustment rate and exception ageing.
It includes the people who will use the system, not only the people who will install it.

Pitfall 10: the business case built on one number

If the entire justification is labour saving, the project will be cancelled the quarter after the first headcount review.

Model at least three benefit streams — labour, stock accuracy and availability — and show each one separately.
Present the pessimistic case, not the optimistic one. A business case that only works at 100 % adoption is not a business case.
Include the running costs that arrive in year two: labels, repairs, software, and the person who now has to own the data.

What good deployments do instead

The pattern is consistent across the projects that worked.

Start from a business decision that is currently wrong, not from a technology that is currently interesting.
Tag a small, closed population completely, rather than a large population partially.
Measure a baseline before the first tag is applied; without it, every later claim is an opinion.
Budget for the boring parts: label application, antenna testing, exception handling.
Define the exit criteria before the pilot starts, and be willing to stop.