IIoT ROI is the question every plant manager asks before approving a connected-machines project, and it is the question most proposals answer badly. This guide gives you a practical framework to quantify downtime, energy and quality gains, list every cost line honestly, and turn the result into a payback period and net present value you can defend in a budget meeting. You will also get a small Python model you can adapt to your own data.
Why Most IIoT Business Cases Fall Apart
An Industrial IoT proposal usually dies for one of three reasons. First, the benefits are written as adjectives: "better visibility", "smarter decisions", "digital transformation". Finance cannot discount an adjective. Second, the costs only include hardware and software licences, and the integration, data modeling and change management work shows up later as an unpleasant surprise. Third, the project tries to justify itself on the whole plant at once, so nobody can verify the numbers until the money is spent.
The fix is to tie every benefit to an operational metric you already measure (or can start measuring cheaply), to a baseline, and to a specific mechanism that explains why connected data changes that metric. If you cannot name the mechanism, leave the benefit out of the case. A smaller, credible number beats a large, fragile one.
The IIoT ROI Formula
The arithmetic is simple. The discipline is in the inputs.
Annual net benefit = (downtime savings + energy savings + quality savings + labour savings)
- annual running costs
Simple ROI (%) = (annual net benefit * years - one-time costs) / one-time costs * 100
Payback (months) = one-time costs / (annual net benefit / 12)
NPV = -one-time costs + sum over years of annual net benefit / (1 + discount rate)^year
Use simple payback to get attention and NPV to get approval. Most finance teams have a hurdle rate or a maximum payback period; ask for it before you build the model so you know the target.
Benefit Levers and How to Measure Them
Each lever below needs a baseline, a mechanism and a conservative improvement assumption. Write all three down.
| Lever | Baseline metric | Mechanism enabled by connected data | How to value it |
|---|---|---|---|
| Unplanned downtime | Hours of unplanned stops per machine per year | Condition alerts, faster fault diagnosis, earlier maintenance | Lost contribution margin per hour plus overtime and expediting |
| Micro-stops and speed losses | OEE performance component | Visibility of short stops nobody logs manually | Extra good units per shift times margin per unit |
| Energy | kWh per unit produced, peak demand | Idle-state detection, compressed air leak detection, load shifting | Tariff per kWh plus demand charges |
| Scrap and rework | Scrap rate, rework hours | Process parameter tracking linked to quality results | Material cost plus labour plus disposal |
| Manual data collection | Hours spent on clipboards and spreadsheets | Automatic counts, states and reports | Loaded labour rate times hours freed |
| Quality escapes | Customer complaints, warranty cost | Traceability of process data per batch | Avoided claims, often valued as risk reduction |
Valuing downtime correctly
The most common mistake is multiplying downtime hours by revenue per hour. Revenue is not lost if the plant can recover the output later on overtime or idle capacity. The honest value is the contribution margin of output that is truly lost, plus the cost of recovering the rest (overtime, expedited freight, extra changeovers). For a constrained bottleneck machine, lost hours usually are lost output. For a machine with spare capacity downstream, the value can be much lower.
Valuing energy correctly
Energy savings come from two places: consumption (kWh) and demand peaks (kW), which many industrial tariffs bill separately. A connected meter on each major load tells you when machines idle with motors, heaters or compressors still running. Value only the idle consumption you can realistically switch off, and use your actual tariff structure rather than an average price.
Valuing quality correctly
Quality gains are real but slow to prove, because you need enough batches to separate signal from noise. Include them in the case, but consider putting them in a "phase two" column that is not required to reach payback. This keeps the core case robust.
The Cost Side: Every Line Item
A credible IIoT ROI model lists costs that proposal writers like to forget.
- Sensors and retrofits. Current clamps, vibration sensors, temperature probes, energy meters, plus mounting and cabling. See our guide on how to retrofit legacy machines for IoT for the typical options.
- Edge gateways. Hardware, enclosures, power supplies and spares. Protocol conversion from Modbus, OPC UA or PLC drivers happens here.
- Network work. Switches, VLANs, firewall rules, possibly cellular modems for remote sites.
- Messaging infrastructure. The MQTT broker that connects edge to consumers. A self-hosted broker has server, patching, certificate and on-call costs; a fully managed MQTT service turns that into a subscription.
- Data storage and visualisation. Historian or time-series database, dashboards, licences.
- Integration and data modeling. Mapping tags to a consistent topic structure and units. This is frequently the largest engineering cost.
- Internal labour. OT engineers, IT security reviews, operators trained on new screens.
- Running costs. Subscriptions, cellular data, support contracts, replacement sensors.
- Contingency. A percentage for unknowns, especially on the first line you connect.
Where Messaging Costs Fit
Messaging is rarely the largest cost in an IIoT project, but it is the one that scales with every machine you add, so model it from the start. Three numbers drive it: the number of concurrent connections (one per gateway or device that talks MQTT), the message rate, and the message size.
Two design choices move these numbers a lot. Publishing on change instead of on a fixed timer, described in our article on report by exception, cuts message volume for slow-moving values such as temperatures and states. Aggregating many tags into one gateway connection keeps the connection count low even when the tag count is high.
With ConnectMQ you can size the broker by plan rather than by servers. The Serverless (Free) plan allows up to 25 connections, QoS up to 1 and 256 KB messages, which is enough for a pilot line. Serverless (Paid) raises that to 1,000 connections with QoS 2, 1 MB messages and shared subscriptions, and Dedicated gives you an isolated cluster when a site needs it. Because the plan limits are fixed, the messaging line in your ROI model is a known subscription, not an estimate of server hours and engineering time. If you are comparing hosting options, our overview of a cloud MQTT broker explains the trade-offs.
A Python Model You Can Adapt
The script below keeps all assumptions in one dictionary so you can share it with finance and change inputs in front of them. The values are illustrative placeholders, not benchmarks; replace every one with your own baseline data.
# iiot_roi.py - a transparent IIoT ROI model. Replace every input with your own data.
inputs = {
# Downtime
"machines": 8,
"unplanned_downtime_hours_per_machine": 120, # baseline from maintenance logs
"downtime_reduction_pct": 0.15, # conservative assumption
"margin_lost_per_downtime_hour": 400.0, # contribution margin, not revenue
# Energy
"idle_kwh_per_machine_per_year": 9000,
"idle_kwh_avoidable_pct": 0.30,
"energy_price_per_kwh": 0.18,
# Quality
"scrap_cost_per_year": 60000.0,
"scrap_reduction_pct": 0.05,
# Labour
"manual_reporting_hours_per_week": 10,
"loaded_labour_rate": 45.0,
# Costs
"one_time_costs": 85000.0, # sensors, gateways, integration, training, contingency
"annual_running_costs": 14000.0, # broker plan, storage, dashboards, support
"years": 5,
"discount_rate": 0.10,
}
def annual_benefits(i):
downtime = (i["machines"] * i["unplanned_downtime_hours_per_machine"]
* i["downtime_reduction_pct"] * i["margin_lost_per_downtime_hour"])
energy = (i["machines"] * i["idle_kwh_per_machine_per_year"]
* i["idle_kwh_avoidable_pct"] * i["energy_price_per_kwh"])
quality = i["scrap_cost_per_year"] * i["scrap_reduction_pct"]
labour = i["manual_reporting_hours_per_week"] * 48 * i["loaded_labour_rate"]
return {"downtime": downtime, "energy": energy, "quality": quality, "labour": labour}
def evaluate(i):
b = annual_benefits(i)
gross = sum(b.values())
net = gross - i["annual_running_costs"]
payback_months = i["one_time_costs"] / (net / 12) if net > 0 else float("inf")
roi_pct = (net * i["years"] - i["one_time_costs"]) / i["one_time_costs"] * 100
npv = -i["one_time_costs"] + sum(net / (1 + i["discount_rate"]) ** y
for y in range(1, i["years"] + 1))
return b, gross, net, payback_months, roi_pct, npv
if __name__ == "__main__":
b, gross, net, payback, roi, npv = evaluate(inputs)
for k, v in b.items():
print(f"{k:>10}: {v:12,.0f} per year")
print(f"{'gross':>10}: {gross:12,.0f} per year")
print(f"{'net':>10}: {net:12,.0f} per year")
print(f"payback : {payback:8.1f} months")
print(f"ROI : {roi:8.1f} % over {inputs['years']} years")
print(f"NPV : {npv:12,.0f}")
# Sensitivity: what if every improvement is only half as good?
pessimistic = dict(inputs)
for key in ("downtime_reduction_pct", "idle_kwh_avoidable_pct", "scrap_reduction_pct"):
pessimistic[key] = inputs[key] / 2
*_, p_payback, p_roi, p_npv = evaluate(pessimistic)
print(f"pessimistic payback: {p_payback:.1f} months, NPV: {p_npv:,.0f}")
Run it with python iiot_roi.py. The sensitivity block at the end matters more than the headline figure: if the project still pays back when every improvement is halved, the case is robust. If it only works in the optimistic scenario, shrink the scope or find a stronger lever.
Prove It With a Pilot Before You Scale
A spreadsheet is a hypothesis. The fastest way to replace assumptions with measurements is a narrowly scoped pilot on one line or a handful of machines, run long enough to capture a representative production mix. Our guide to running an IIoT proof of concept covers scope and success criteria in detail.
Keep the pilot cheap and reversible:
- Pick the lever with the clearest baseline, usually downtime or energy on a bottleneck asset.
- Connect the data through an edge gateway publishing to an MQTT broker, with a topic structure you would be happy to keep at scale.
- Use a free broker tier for the pilot so infrastructure is not a procurement question. You can prototype the data flow on the public MQTT test broker with non-sensitive sample data, then move to private credentials.
- Agree in advance what result counts as success and who signs off.
- Record the actual integration hours. This is the number that most improves your scale-up cost estimate.
A minimal pilot publisher can be as simple as this, sending one machine state to a unique topic on the public broker:
mosquitto_pub -h broker.connectmq.com -p 1883 -i roi-pilot-7f3a \
-t "connectmq/demo/7f3a/line1/press1/state" \
-m '{"state":"running","kw":11.4,"ts":"2026-10-16T08:00:00Z"}' -q 1 -r
Presenting IIoT ROI to Finance
When you take the model to the budget meeting, structure it so reviewers can challenge inputs rather than the whole idea:
- Show the baseline data source for every input.
- Separate hard savings (energy, scrap, overtime) from soft or strategic value (traceability, faster decisions).
- Show the pessimistic scenario next to the expected one.
- State what is out of scope and what a phase two would add.
- Show the scale-up cost per additional machine, which is usually far lower than the pilot cost because the architecture, broker and topic model already exist.
For the broader architectural context, our industrial IoT with MQTT pillar explains how gateways, brokers and consumers fit together, and the IIoT architecture article goes deeper on layers.
Get Started with ConnectMQ
The cheapest part of an IIoT business case should be the part you can start today. Create a broker at app.connectmq.com on the free Serverless plan with no credit card, connect your pilot gateway with the generated username, password and client ID, and watch real machine data in the live topic explorer while your ROI model fills with measured values. When the pilot proves the case, ConnectMQ scales with paid and dedicated plans without changing your topic structure.
Frequently Asked Questions
What is a good payback period for an IIoT project?
There is no universal number; it depends on your company's hurdle rate and risk appetite. Ask finance for their threshold before building the model, and show both expected and pessimistic payback against it.
Should I use revenue or margin when valuing downtime in IIoT ROI?
Use contribution margin on output that is truly lost, plus the cost of recovering the rest. Revenue per hour overstates the benefit whenever the plant can make up output later.
How much do MQTT messaging costs affect IIoT ROI?
Usually they are a small line compared with sensors and integration, but they scale with every device. Model connections, message rate and size, and use report by exception to keep volume low.
Can I calculate IIoT ROI before installing any sensors?
You can build a hypothesis from maintenance logs, energy bills and scrap reports, but treat it as a starting point. A short pilot replaces the weakest assumptions with measured data.
