How to Calculate Automation ROI Before You Spend a Penny

The number most vendors give you is not wrong, it is incomplete

Automation ROI arithmetic is easy enough to do on the back of an envelope, which is why almost everyone does it badly. The usual version goes: this takes 20 hours a week, our people cost £20 an hour, so that is £20,800 a year saved. The build costs £12,000, so we are ahead in seven months.

Every number in that sentence is defensible and the conclusion is still usually wrong, because three costs are missing and one saving is imaginary. Here is the version we use when scoping, including the parts that make our own quotes look less impressive.

Step 1: measure the task, not the job

Automate a task, not a role. Time the specific path you intend to change — “take an order from email into the order system” — and count only that. If you time the whole job you will include work the automation cannot touch, and the model will flatter itself.

Do this by observation for a week rather than by asking. Self-reported times are consistently wrong in both directions: people under-report tasks they find tedious and over-report tasks they find important.

Step 2: use a fully-loaded hourly cost

Salary alone understates the number by roughly a third. Take gross salary, add employer NI, pension, holiday cover, software licences and a share of overheads, then divide by actual worked hours rather than contracted ones.

Step 3: subtract the work that survives automation

No automation removes 100% of a task. Exceptions get reviewed, someone still handles the awkward customer, and there is a weekly glance at what went through. A realistic figure is that a well-built automation removes 70–90% of a mechanical task and 40–60% of a judgement-heavy one.

If a proposal assumes total elimination, ask what happens to the 5% of records that do not match. The answer is usually “a human looks at them”, and that human needs to be in the model.

Step 4: count error costs separately, because they are usually the bigger number

Time saved is the headline. Errors avoided are frequently worth more and are almost always left out. Wrong deliveries, credit notes, duplicate orders, missed SLAs, refunds issued to keep a customer quiet — pull three months of those from the accounts and attribute what was caused by manual handling.

One distributor we worked with found the error line dwarfed the labour line: the staff time was worth about £30,000 a year, the returns and credits caused by manual entry were worth another £100,000+. The automation case was made on the second number, not the first.

Step 5: be honest about headcount

This is where most models quietly cheat. If you are not going to make anyone redundant — and most owners do not want to — then the saving is capacity, not cash. Capacity is genuinely valuable: it means growing 40% without hiring. But it does not reduce this year’s payroll, and a board paper that implies it will is going to be embarrassing later.

Write down in advance what you will do with the freed hours. “Take on more work without hiring” is a real answer. “They will be more productive” is not.

Step 6: add the running costs nobody quotes

The build price is not the cost of ownership. Include API and licence fees, hosting, and a maintenance allowance — integrations break when the other side changes, and something always changes. Budget 10–20% of the build cost annually and you will rarely be surprised.

• Third-party API tiers that jump once volume rises
• Hosting and monitoring, typically modest but never zero
• Change work when a supplier alters their format
• Internal time for exception handling in the first two months

Putting it together

Annual benefit = (hours removed × fully-loaded rate) + (error costs avoided) − (running costs). Payback in months = build cost ÷ (annual benefit ÷ 12).

Run it twice: once with your realistic numbers and once with the pessimistic ones — 60% of the time saving, half the error reduction, top of the running cost range. If the pessimistic case still pays back inside two years, it is a sound project. If only the optimistic case works, the project is a bet rather than an investment, and it should be scoped smaller.

Frequently asked questions