Most IoT business cases look great on the slide. They count the obvious savings, divide by the price of the sensors, and land on a number that gets the project approved. Then the deployment goes live, the real bills arrive, and the savings turn out to be softer than anyone admitted. The math was not wrong. It was incomplete.
A real ROI calculation does two things the slide version skips. It totals the full cost of ownership, not just the hardware. And it separates the savings you can measure from the savings you are hoping for. Get both right and you have a number you can defend. Get either wrong and you are guessing.
Here is a method you can actually use.
Start with the full cost of ownership
The first mistake is treating the sensor price as the cost. The sensor is the cheapest part. The total cost of ownership includes everything you will pay across the life of the deployment, and most of it is recurring.
Break it into categories so nothing hides:
Hardware. Sensors, gateways, and any edge devices. Include spares and the units that fail in the first year, because some will.
Integration. The engineering time to connect devices, write parsers, build dashboards, and wire up alerts. This is often the largest line in year one and the one people forget to price.
Connectivity. Cellular plans, LoRaWAN network access, or whatever moves the data. This recurs every month, per device, forever.
Platform and storage. The cloud layer that ingests, stores, and serves the data. Recurring.
Ongoing operations. Someone monitors the system, replaces dead sensors, updates firmware, and answers the alerts. This is a real cost even when no one budgets for it.
Add a line for the cost of the deployment failing or stalling, because a pilot that never scales still cost you the pilot. Total all of it across three years, not one. A deployment that pays back in month eight on a one-year view can look very different once year-two connectivity and operations are in the column.
Separate hard savings from soft savings
Now the benefit side. The single most useful thing you can do is split your savings into two columns and never mix them.
Hard savings are measurable. You can point at a number that changed:
- Energy spend reduced because monitoring caught equipment running inefficiently. Energy optimization commonly targets reductions in the range of ten to twenty percent of the monitored load, though your number depends entirely on your baseline.
- Labor hours saved because someone no longer drives out to read a meter or check a tank manually. Count the truck rolls avoided and multiply by the loaded cost of the trip.
- Product loss avoided. In cold chain, early temperature alerts prevent spoiled shipments. If you historically lose a known number of loads a year, the value of catching them is concrete.
- Unplanned downtime avoided through predictive maintenance. If a facility has a history of equipment failures at a known cost each, and condition monitoring prevents some of them, the avoided cost is real and provable after the fact.
Soft savings are real but harder to put a price on:
- Compliance and audit evidence you did not have before.
- Safety incidents avoided.
- Faster decisions because the data exists at all.
- Customer trust from being able to prove a shipment stayed in range.
Soft savings belong in the case. They just do not belong in the same column as hard savings, and they should never carry the ROI on their own. If the project only works once you assign a generous dollar value to morale and agility, the project does not work.
Estimate the payback period and test it
With full cost and hard savings in hand, the payback period is the time it takes for cumulative hard savings to cover cumulative cost. Predictive maintenance and monitoring deployments often land somewhere in the twelve to eighteen month range, but treat that as a sanity check, not a target. Your payback is whatever your own numbers say.
Then pressure-test the assumptions before anyone signs:
- What baseline are the savings measured against, and is that baseline documented or remembered? Remembered baselines flatter every project.
- What happens to the payback if the savings come in at half? If the case only survives at the optimistic number, it is not a case, it is a hope.
- Who acts on the alert? An energy or maintenance alert saves nothing if no one is responsible for responding. The savings live in the action, not the data.
- Does the recurring cost grow with scale faster than the savings do?
A case that survives those four questions is one you can take to a CFO.
When the IoT ROI does not add up
The honest part. Plenty of IoT projects should not happen, and the math will tell you so if you let it.
IoT rarely pays back when the asset being monitored is low value. Putting a connected sensor on equipment that costs little to replace and fails without consequence is hard to justify. The sensor, connectivity, and operations cost more than the thing they protect.
It rarely pays back at low unit counts unless each unit is high value. The integration cost is mostly fixed. Spread across ten cheap assets it dominates the case. Spread across ten thousand, or across ten critical ones, it disappears.
And it never pays back when no one owns acting on the data. This is the most common quiet failure. The dashboards go live, the alerts fire, and nothing changes because responding to them was never anyone’s job. The savings were always conditional on someone doing something, and no one was assigned.
If your case depends on monitoring cheap assets, in small numbers, with no one accountable for the response, the right answer is not a smaller deployment. It is no deployment. Saying that early is cheaper than proving it after eighteen months.
Where TagoIO fits
ROI math has a cost side, and the platform layer sits squarely on it. TagoIO is the layer that ingests device data, stores it, runs the logic, and serves the dashboards and alerts. How that layer is priced and how much engineering it takes to stand up directly affect your integration and operations lines.
A few specifics that touch the cost column. TagoIO connects to 500+ device integrations, so connecting existing hardware is configuration rather than a custom build, which lowers the integration line. Serverless Analysis scripts run your logic without a server to provision or maintain, which keeps the ongoing operations cost down. The platform is multi-tenant, so a deployment across sites or clients does not multiply the infrastructure. For regulated work, TagoIO is ISO 27001 certified and GDPR-aligned, which is part of the compliance evidence on the soft-savings side.
None of that changes the savings side of your equation. Your hard savings come from your own operations. The platform affects what the deployment costs to build and run, and a lower cost of ownership is the easier half of a better payback.
Next steps
- See deployments and the problems they solve: tago.io/use-cases
- Check how the cost side is priced: tago.io/pricing
- Start building and price your own deployment: admin.tago.io
