An RFID business case is usually written backwards: someone decides the project should happen, then finds benefits large enough to justify it. The result survives the meeting and dies in the second year, when nobody can show that the promised savings appeared. The fix is not a stronger slide deck; it is a model with visible inputs, defensible baselines and a stated ramp.

ROI is a model with assumptions, not a number

A single percentage is a claim about the future with the reasoning hidden.

Every ROI figure rests on assumptions about volume, wage rates, error rates and adoption.
State the assumptions explicitly, because that is what a reviewer will attack.
Distinguish measured baseline data from estimates borrowed from a vendor brochure.
Build the model so that a wrong assumption changes the answer visibly rather than silently.
The deliverable is a model a sceptical controller can audit, not a slide.

The benefit categories that survive audit

Only four categories usually hold up under scrutiny.

Labour hours removed from counting, receiving and searching.
Shrink reduction that is actually measured, not assumed.
Sales recovered from better availability, which is the hardest to prove.
Working capital released by lower safety stock, which is real but slow.
Everything else — "accuracy", "visibility", "customer experience" — is a mechanism, not a benefit.

Labour savings: the honest calculation

Count the minutes, then subtract the minutes the new process adds.

Time each task before the project: cycle count, goods receipt, put-away, picking search time.
Multiply by the loaded hourly rate, not the base wage.
Subtract the new work the system creates: tagging, exception handling, reconciliation.
Account for the productivity dip in the first two quarters, because it always happens.
Cap the saving at the available hours; a 120 percent labour saving is a modelling error.

Shrink: separate the recoverable from the theoretical

Shrink is where RFID business cases most often inflate.

Total shrink includes theft, admin error, supplier fraud and process loss; RFID fixes only some.
Measure the baseline with an independent count, not with the system being replaced.
Attribute only the portion your process actually changes, and say which portion that is.
Recovery of known errors is fast; prevention of unknown theft is slow and partial.
A vendor claiming 50 percent shrink reduction is describing a best case in a specific format.

Recovered sales: the most abused line

Availability-driven sales recovery is real and routinely overstated.

The mechanism is sound: an item not on the shelf cannot be sold.
The measurable version is the reduction in out-of-stock events on high-turnover items.
Convert to sales only with the actual item margin and the actual capture rate, not the theoretical one.
Some lost sales go to a competitor, some never happen; the split is a local measurement.
Present this line with a range, and make the low end the one used in the decision.

The cost side, including the invisible ones

Total cost of ownership is larger than the purchase order.

Tags, consumables and re-tagging of returns are recurring, not one-off.
Readers, antennas, cabling, mounting and power are capital plus installation labour.
Integration with the ERP is usually the largest single line and the most underestimated.
Training, process redesign and the temporary productivity loss are real costs.
Ongoing support, spare parts, firmware updates and tag price inflation belong in the model.

Timing: cash flow and payback

A payback period that ignores the ramp is a fantasy.

Benefits arrive after adoption, not at go-live; model a ramp of three to four quarters.
Costs arrive early, which means the cash trough is deeper than the annual view suggests.
Discount the cash flows, or at minimum show both nominal and discounted payback.
Compare against the company's hurdle rate, not against zero.
Show the cumulative cash curve; it communicates more than any single ratio, and mark the quarter where it crosses zero under both the base case and the pessimistic one.

Sensitivity analysis and break-even

The useful question is how wrong you can be and still be right.

Vary the three assumptions that matter most: adoption rate, shrink reduction and tag cost.
Find the break-even value of each, and compare it against the plausible range.
If break-even requires a 90 percent adoption in year one, the case is fragile.
Present a tornado chart; it shows which assumption deserves the next study.
A model that is robust across the plausible range is worth more than a high central estimate.

Risk-adjusted ROI

Some risks are technical, some are organisational, and they price differently.

Technology risk: read rate in the real environment, tag durability, reader coverage.
Integration risk: ERP customisation, master data quality, legacy interfaces.
Adoption risk: the team reverting to paper when the system is inconvenient.
Apply explicit probability weights, or at least a documented discount for each risk.
The risk-adjusted number is the one to take to the investment committee.

Building the model people will challenge

Structure decides whether the model is believed.

One sheet for inputs, one for calculations, one for output; never mix them.
Every input cell has a source, a date and an owner.
Hard-code nothing that could change; parameterise volumes, rates and prices.
Version the model, keep the version that was approved, and record who approved it and on what date.
Document what would make you revise the case, in advance.

Post-implementation measurement

The model earns its credibility in the follow-up, not in the pitch.

Define the measurement method before go-live, or the numbers will be chosen afterwards.
Measure the same baseline metrics, in the same way, at the same cadence.
Report variance against the model quarterly, including the assumptions that were wrong.
Feed the realised values back into the next site's model.
A business case that was measured is an asset; one that was never revisited is a rumour.