How to Calculate ROI Before Starting an IoT Project

Before estimating any benefit, quantify the current cost of the problem the project is meant to fix — how often it happens, and what it costs each time in lost product, downtime, wasted labour, or a missed customer commitment. This baseline is what every later ROI claim gets measured against, so it needs to be as accurate as the business can make it, not a rough guess pulled together to justify a decision already made.

Where exact figures aren't available, a defensible estimate built from a few weeks of manual tracking is far more useful than an assumed number, and it gives the business something concrete to compare against once the pilot is running.

Sensor hardware is often the smallest and most visible cost, which makes it easy to under-budget everything around it. A realistic estimate includes installation labour, any connectivity or data plan costs that recur monthly, the software or platform that turns readings into alerts, and the ongoing cost of maintenance, calibration and battery replacement over the life of the deployment.

Rather than stating a specific figure — costs vary too widely by industry, site condition and sensor count to state a reliable number here — it's worth building out these categories explicitly for your own project and getting quotes for each one, rather than assuming the sensor price is a fair proxy for the total cost.

A monitoring system's benefit only materialises if someone actually responds to what it reports, in time to matter. It's worth estimating benefit on a realistic view of response capacity — do you have someone available at 2am if a cold room alert fires, or does the benefit assume a response that, in practice, won't happen for eight hours.

Consider a mid-sized ceramics and tile manufacturer evaluating kiln temperature monitoring. The theoretical benefit of catching a temperature excursion early is large, but if the only person who can act on that alert is off-site and unreachable overnight, the realistic benefit is smaller than the best-case number a vendor might quote — and the business case should reflect that honestly.

Rather than committing to a full rollout based on estimated numbers, run a bounded pilot on one line, one site, or one asset type first, and treat the baseline and benefit estimates as hypotheses to be tested, not settled facts. A pilot is where unrealistic assumptions about response time, data quality or false alarm rates get caught while the cost of being wrong is still small.

It's worth deciding in advance what result would justify scaling and what result would mean stopping or redesigning — without that decided ahead of time, there's a tendency to keep a struggling pilot running because stopping feels like admitting the initial decision was wrong.

After the pilot period, compare actual results against the baseline recorded at the start — not against the original estimate, which may have been optimistic. The comparison that matters is the same measure, before and after, over the same conditions.

This measurement also needs to include the system's ongoing burden, not just its benefit: time spent responding to false alarms, maintenance hours, and any software subscription cost. A pilot that reduced downtime but created a comparable amount of new alert-handling work hasn't necessarily delivered the ROI it looks like on the benefit side alone.