How to Calculate ROI Before Starting an IoT Project

Before you price a single sensor, write down what the problem costs the business now, in lost product, idle machine hours, wasted labour and missed delivery dates. Count every occurrence, honestly. Every later ROI claim is measured against this baseline, so a rough guess here quietly corrupts the downtime, spoilage or rework savings you promise the budget holder.

If exact figures do not exist, spend three or four weeks logging events by hand on a clipboard or shared sheet and use that tally as your estimate. A measured estimate beats an assumed one. The maintenance planner’s downtime sheet, the stores issue log and the customer complaints file are good starting sources for that tally, and they cost nothing to open. It also gives the pilot something concrete to be judged against, which matters when the vendor’s sample numbers look far better than your own floor.

Sensors are the smallest line. A realistic budget adds installation labour, gateways, monthly connectivity or data plans, the platform that turns readings into alerts, and calibration and battery changes across the deployment’s life. Budgeting around the hardware price alone is how projects look cheap in the proposal and expensive by the second year of running them, once the invoices arrive.

No honest number fits every site. Build the list, category by category, and ask for a written quote on each one: installers, the network provider, the platform vendor and whoever will recalibrate the devices. Never treat sensor price as a proxy. Ask the vendor to itemise gateways, mounting brackets, cabling, commissioning days and the first year of support in the quote, because lump sums conceal exactly the lines that overrun.

A monitoring system only pays back when someone responds to its alert in time to change the outcome, so estimate benefit from real response capacity. Who answers at 2am? If a cold-room alarm fires overnight and the only person who can act lives an hour away, the benefit assumes a response that will not happen.

Consider a tile maker monitoring kiln temperature, where catching an excursion early looks valuable on paper and the vendor’s case study shows a large saving. Then ask who can act. If the kiln supervisor is off site overnight and nobody else holds the authority to stop a firing, the realistic benefit is far smaller than the quoted figure. Write the response plan into the business case, with a named person, a phone number that is answered and an agreed time limit, or cut the benefit line.

Instead of committing to a full rollout on estimated numbers, instrument one production line, one warehouse or one asset type and treat every estimate as a hypothesis. The pilot is the test. It exposes unrealistic assumptions about response time, data quality and false-alarm rates while a mistake is still cheap, before contracts for a hundred devices are signed.

Agree in writing, before the pilot starts, what result justifies scaling and what result means stopping or redesigning the setup, so the numbers settle the argument. Struggling pilots rarely stop themselves. Stopping feels like admitting the first decision was wrong, so without a pre-agreed threshold a weak pilot limps along for months and eats the team’s time.

When the pilot ends, compare the measured result against the baseline you recorded at the start, not against the optimistic estimate in the proposal. Same measure, same conditions, before and after. Keep a simple ledger of avoided events, such as spoiled batches, unplanned stoppages and emergency call-outs, and price each at what it genuinely cost before the sensors went in.

Include the system’s running burden alongside its benefit: hours spent chasing false alarms, maintenance visits, battery swaps and the monthly platform subscription. Downtime fell, but alerts rose. A pilot that cut stoppages yet created a matching pile of alert-handling work has not delivered the return its benefit column suggests on its own.