Cost Savings from Automation: The Five-Variable Model, and How to Measure Each One

Why most automation ROI calculations are worthless

The calculation you see almost everywhere looks like this: "six hours a week times an hourly wage, minus the cost of the system, equals savings". It fails in three places. First, it counts saved hours as if they were saved money — and only rarely is that true. Second, it multiplies by gross salary rather than the loaded employer cost, missing a significant share. Third, it ignores the error rate entirely, which is the one variable in the model that can be negative: automation can raise the cost of errors, not only lower it.

Below is a model that takes all five of those variables seriously, instrumentation instructions for each, and a full worked example.

The model

net monthly saving = (H × C) + ΔE − M
payback in months  = I ÷ net monthly saving

H  = person-hours saved per month, after subtracting oversight time
C  = loaded hourly cost to the employer
ΔE = reduction in monthly error cost (negative if errors got worse)
M  = monthly running cost: model, hosting, monitoring, maintenance
I  = one-time implementation cost

The formula is deliberately simple. The difficulty is not the arithmetic but that four of the five variables are usually estimated out of thin air. Here is how to measure each one.

H — hours saved: the most inflated variable

Do not ask the team how long the task takes. People estimate repetitive tasks with a consistent bias. Instead, measure for two weeks before implementation:

• Count the actual number of events — how many orders, how many inquiries, how many reports. Pull that number from the system, not from memory.
• Time a sample of ten events with a clock, from the moment the task arrived until it closed, interruptions included.
• Separate the normal case from the exception. Automation usually handles the routine and leaves the exceptions, and an exception typically takes several times as long.

Then apply the subtraction everybody forgets: after automation there is still oversight time. Even a case handled successfully gets eyeballed, at least in the first months. H is the difference between total time before and total time after, review included — not the share of tasks automated multiplied by the original duration.

C — loaded hourly cost: not the number on the payslip

Take your monthly employer-cost report for the relevant role — the figure that includes statutory contributions, not gross pay — and add the costs attached to the person: workspace, equipment, software licences. Divide by productive hours per month, not contracted hours. Contracted hours minus vacation, sick leave, training and internal meetings. That denominator is meaningfully smaller than it feels, which is why C is higher than intuition suggests.

If several roles perform the task, weight by who actually performs it. A manager approving a quote and an assistant typing it are not the same C.

I — implementation cost: count what is not in the quote

Five components, and the last three are the ones that get forgotten:

1. Discovery and mapping of the process as it is actually performed, not as it is documented.
2. Build and connection to systems, including auth and permissions.
3. Testing against real data and the first round of fixes.
4. Internal staff time — every hour your own expert spent explaining, checking and approving belongs in I.
5. Organisational rollout — training, writing the procedure, and the period where people still do the task manually "just in case".

M — monthly running cost

Three measurable components and one that tends to be omitted: model or API usage, hosting and compute, and monitoring. The fourth is the maintenance tail: a vendor moves an endpoint, a credential expires, a response shape changes. Do not guess a percentage — log your actual maintenance hours across the first three months, multiply by C, and that is your real M from then on.

ΔE — change in error cost: the variable that can be negative

This is the variable almost no calculation includes, and it decides whether the result is trustworthy. Measuring it needs three things:

1. A countable definition of an error event. Not "quality dropped" but "an order that had to be corrected after intake", "a refund issued because of a fault", "an inquiry answered wrongly that came back".
2. A baseline rate: how many such events per 100 operations, measured before implementation. Without that number there is nothing to compare against, and it cannot be reconstructed after the fact.
3. An average cost per event: correction time times C, plus any direct cost — a credit, a re-delivery, a service hour.

Measure the same rate after implementation, using the same definition. If the rate went up, ΔE is negative and the model must show it. Automation replaces human errors with a different kind: it is consistent, so when it is wrong it is wrong the same way in every case until somebody notices.

A full worked example

Disclosure: every number in this section is a hypothetical input chosen to demonstrate the model. These are not results measured at customers. Substitute the numbers you measured in your own business using the instructions above; without them, the output is an organised guess rather than a forecast. Figures are in shekels.

The example process: intake of orders arriving by email into the order system, plus sending an initial confirmation to the customer.

Step 1 — H. Assume 60 orders a week and a timed sample showing 9 minutes per order. That is 9 hours a week, about 39 hours a month. The automation handles 75% of orders, but each one is still reviewed for 2 minutes: 45 orders times 2 minutes is 1.5 hours a week. The remaining 25% stay fully manual: 15 times 9 minutes is 2.25 hours a week. Human time after: 3.75 hours a week instead of 9. The difference is 5.25 hours a week, so H ≈ 23 hours a month. Note that the naive calculation — 75% of 39 — would have given 29 hours, about a quarter too high.

Step 2 — C. Assume a monthly employer cost of 24,000 for the performing role and 150 productive hours a month. C = 160 per hour. So H × C = 23 × 160 = 3,680 a month.

Step 3 — ΔE. The defined error event: an order captured incorrectly that has to be corrected. Rate before: 4 per 100. 260 orders a month gives 10.4 events. After implementation, assume the rate rose to 5 per 100, so 13 events — the automation captured one field wrongly, consistently. Average cost per event: 40 minutes of correction plus an apology to the customer, about 150. Before: 1,560. After: 1,950. ΔE = −390 a month.

Step 4 — M. Model and API usage 450, hosting and monitoring 120, and actual maintenance of 2 hours a month which is 320. M = 890.

Step 5 — the result.

net monthly saving = 3,680 + (−390) − 890 = 2,400
I = 18,000
payback = 18,000 ÷ 2,400 = 7.5 months
first-year net = 2,400 × 12 − 18,000 = 10,800

Notice what happened: the naive calculation would have shown 3,680 in monthly savings and payback in under five months. Two variables alone — oversight time and the increase in errors — moved payback by more than two and a half months.

Sensitivity: how fragile is the conclusion

Run the model a second time with a smaller H. If instead of 23 hours you actually get 15, the net monthly saving falls to 15 × 160 minus 390 minus 890, that is 1,120, and payback jumps to 16 months. On the same hypothetical inputs the break-even point is H = 8 hours a month — below that the automation loses money every month, before the investment is counted. Paying back the investment within a year needs about 17.5 hours.

The practical conclusion: if your estimate of H is anywhere near break-even, do not run the project — go and measure H properly. The difference between 15 and 23 hours is the difference between a good decision and a bad one, and it lives in two weeks of measurement.

Three ways to fool yourself, and how not to

• An hour saved is not a shekel saved. This is the expensive mistake. Freed time becomes money in exactly two cases: a hire that would have happened was avoided, or the freed hours went into revenue-producing work you can point at. If neither happened, you improved quality of life in the business — real value, but it does not belong on the savings line.
• The pilot effect. In the first month everyone is paying attention and the process runs unusually well. Measure again in month three, when the enthusiasm has faded and nobody is checking every case.
• The fallback rate. An automation that succeeds on 75% of cases hands 25% back to a person — and often hands back precisely the hard cases, which took longer anyway. If you did not count that, you inflated H.

When the model tells you not to do it

The model is most useful when it says no. Three situations where the result is almost always negative: a process that happens fewer than ten times a month (H is too small to cover M); a process where exceptions are the majority rather than the exception (the fallback rate eats the saving); and a process where the cost of a single error is very high — a wrong charge, a regulatory filing, a legal document — where one negative ΔE erases a year of savings. In the third case, consider automation that prepares but does not execute, leaving approval with a person.

Where it breaks technically, and why that raises I

The hardest variable to estimate up front is I, and the most common reason it overruns is that the system you need to connect to offers no ready interface. If there is no official server, you build the connection layer too — a whole line item in the implementation budget. Before approving a budget, check what exists for your systems: our connection map lists, per system, what was found, the date it was checked, and what the vendor itself says. The "MCP or direct connection" question feeds straight into I and M, and we worked through it in the comparison of MCP versus a direct API.

One more line in I that gets skipped is permissions. An automation handed a broad token so that "nothing gets stuck" is a saving booked against a risk that was not booked. Defining least privilege per tool takes time, and that time belongs to I — see the guide to MCP security.

Three steps to start

1. Pick one process and count it for two weeks: event count from the system, a timed sample, and a baseline error rate. Without those three numbers there is no model.
2. Compute C from the employer-cost report divided by actual productive hours.
3. Run the formula twice — once with your estimate and once with H reduced by a third. If both results are positive you have a decision. If only one is, you have more measuring to do.

Summary

Cost savings from automation is a calculation, not a promise, and it rests on five numbers most of which do not exist in a business until somebody bothers to measure them. The two variables that decide whether the result is real are the oversight time left after automation and the change in error rate — and both work against the saving, not for it. Measure them and you have a decision; skip them and you have a nice-looking number.