How do you calculate labour savings from building automation?

The honest answer is task by task. You measure how long each affected task takes today and how often it happens, estimate how much time remains once it is automated, subtract the new work the automation creates, and adjust for how much of the change will realistically happen. What comes out is time released, measured in hours. That figure becomes a cost saving only if the organisation does something with the time that removes a cost, such as bringing subcontracted work in-house, avoiding a planned recruitment or changing staffing.

Those are two different numbers, and a business case should show them separately, with every assumption stated, so that decision-makers can see which part is measured and which part is a management choice.

Working through the method

List the tasks affected first, and be specific: "monthly manual reading of 40 submeters", not "energy management". The usual candidates are reading rounds, manual data entry, alarm verification visits, report compilation and work-order administration.

Next, measure the baseline. For each task, record how often it happens and how long it takes each time, including travel and recording. Timesheets, work-order data or a short observation exercise are far more reliable than estimates from memory. Note who does the task, too, whether an in-house engineer, a contractor or an administrator, because that determines what the time is worth later.

Then estimate how much time each task will take after automation. Tasks often shrink without vanishing. A plant round may still be needed for visual and audible checks even when readings are collected automatically, and the calculation should say exactly what remains.

Then add the new work, which calculations frequently leave out. Automation creates tasks of its own: reviewing exception reports, investigating automated alerts, maintaining sensors and integrations, managing users and keeping data accurate. These are real hours.

Not every theoretical saving materialises, which is why the calculation needs a realisation factor. People may keep doing the old task alongside the new one for a while, some automation is unreliable at first, and minutes released in scattered fragments across a day are hard to use. State the factor you choose and why, and test the result at a lower value.

Decide, too, what the released time is worth. If it is redeployed to valuable work, describe that work. If it allows a cost to be removed, name the cost and who has agreed to remove it. If neither applies, report it as capacity released and do not convert it into money.

The arithmetic itself is simple:

Net time released = (baseline time − post-automation time) × realisation factor − new task time

A worked calculation

The figures below are assumptions chosen to show the arithmetic. They are not benchmarks for any building or labour market.

The platform also creates work:

With full realisation (a factor of 1.0), the net time released is 158.2 h − 76 h = 82.2 hours per year. With a realisation factor of 0.75, it is (158.2 h × 0.75) − 76 h = 118.7 h − 76 h = 42.7 hours per year.

Because the new work is a fixed cost in hours, a modest shortfall in realisation wipes out almost half of the net benefit. Decision-makers should see that sensitivity.

Some context helps. Assume 1,650 productive hours per full-time employee per year, and substitute your own figure. On that basis, 82.2 hours is about 0.05 of one person's year: roughly two working weeks, arriving in small portions spread across the year. That will not reduce headcount. It may usefully free time for planned maintenance that is currently being deferred.

Only if the released hours displace work that would otherwise be paid for does it make sense to apply a cost rate. Using an assumed fully loaded rate of €40 per hour, purely to illustrate the arithmetic, the result is 82.2 h × €40 = €3,288 per year at full realisation, or 42.7 h × €40 = €1,708 per year at 0.75 realisation. Those figures belong in a business case only alongside the specific cost they replace, such as a subcontracted task that will now be done in-house.

Double counting and other traps

Double counting is the commonest error. If remote monitoring removes a plant-round reading and also reduces call-outs, check that the same hours have not been claimed under both. Travel and set-up are another trap: taking a ten-minute reading out of a round saves little if the engineer still walks to the plant room for other reasons.

Fractions of people are not cash. Small savings spread across many staff rarely change the payroll, and they should be presented as capacity unless a specific decision converts them. Nor should the recurring costs of the automation be left out. Labour savings need comparing with its subscription, maintenance and support costs over the same period; NIST Handbook 135 advises evaluating alternatives over a common study period for exactly this reason, and an ROI calculation brings the two sides together.

The last error is assuming adoption. If staff do not trust the automated readings, they will carry on taking manual ones. Training, good data and a clear decision to stop the old task are all part of realising the saving.

Checking the result

Three to six months after implementation, measure the same tasks again using the same method as the baseline. Record what changed, what new work appeared and whether the released time was used as planned. That comparison is the evidence for deciding whether to extend automation to other buildings.