Design an RFID Pilot Before Buying Readers

An RFID pilot should answer a business question: which objects must be identified, at what points, with what accuracy and exception process. Start with a small representative environment and record missed reads, unexpected reads, tag placement, and operator effort.

The featured image is an illustrative concept, not a product photograph or customer deployment.

Define the event

Specify what a read means. A tag detected near a doorway does not automatically prove a completed transfer, custody change, or inventory count.

Test physical variability

Try real materials, orientations, distances, interference, motion, and nearby tags. Repeat tests during normal operations, not only an empty-room demonstration.

Design exception handling

Operators need a way to confirm an ambiguous read, correct a misidentified asset, and reconcile the event history with the system of record.

Define the event the business will trust

Choose one action, such as an asset leaving a controlled room, and state the physical conditions that should create a business record. A radio read alone may be ambiguous when several tagged items are nearby or a person pauses at the doorway. Pair observations with an operator-confirmed ground truth during the pilot. Count missed reads and false associations separately, and note material, orientation, distance, speed, and antenna placement. This gives the team a measured basis for deciding whether another tag position or workflow step is needed.

An event-definition sheet should show the physical action, tag and reader configuration, expected system record, acceptable timing, and how a person verifies the ground truth. Add a row for a missed read, a nearby unrelated tag, and an item moving in the opposite direction. Record both radio observations and business-event decisions during the pilot. The difference between those counts is important: many reads can still produce poor custody data. Agree on a go/no-go threshold for accuracy and operator correction effort before collecting results. Keep this sheet with the pilot data so later hardware changes can be compared fairly.

Make exceptions visible before scale

Design how staff correct an incorrect asset association, confirm a missing read, and reconcile inventory after a reader outage. Each correction should retain the original event, the reason, and the person who resolved it. Pilot across normal busy periods and unusual cases rather than only in an empty test area. Agree on an accuracy target and operator-effort limit before buying more hardware. Verify device, tag, and accessory compatibility with the vendor for the specific environment. The pilot is successful when the business record is trustworthy and the exception work is manageable, not when the reader produces many events.

Decision checklist

• Choose one measurable use case and baseline.
• Document tag, reader, antenna, and placement conditions.
• Count misses and false associations separately.
• Agree on exception workflow and go/no-go criteria.

A small test before committing

Mark the exact read zone and the business event each successful read should create. Pilot representative tags on real materials at expected orientations and speeds, including crowded and missed-read conditions. Compare read events with a trusted manual count, inspect duplicates, and identify how an operator corrects exceptions. A high raw read count is not enough if events cannot be tied to the right asset or workflow state.

Worked scenario

A hypothetical tool-room pilot may aim to record asset exits. A reader detecting a tag near the door must be compared with actual check-out events; otherwise the project may report reads while custody records remain wrong.

For a scoped application of this decision, see Rugged Hardware & RFID.