Free tool · No email required

Automation ROI calculator

Describe a task somebody does by hand. This works out what it costs you a year, split into the hours and the mistakes, then how long an automation would take to pay for itself. Every intermediate number is on the page so you can check the arithmetic rather than trust it. Nothing you type leaves your browser, because nothing is sent anywhere.

The part most ROI calculators skip is the second half. An automation is not free to own: it has model or vendor spend, it needs maintaining, it will not cover every run, and somebody has to look at the ones it kicks out. All four are priced below, and the payback figure is net of them. Then, underneath, the checks that say when you should not believe the payback figure at all.

1. The manual process

Name one task, not a department. If you cannot write it in six words, it is more than one process and the arithmetic below will average two different things into a number that describes neither.

Time one real run with a stopwatch before you fill these in. Self-reported task times are wrong in both directions: people underestimate the routine bit and forget the two minutes of finding the file, and they overestimate anything they resent.

Your own staff cost, not a vendor rate and not ours. Loaded means salary plus employer taxes, benefits, software, and the share of a desk, which is typically a quarter to a half above the salary line depending on where you employ people. Use your finance team’s figure if they have one.

2. What going wrong costs

The softest pair of numbers on this page, and the pair most likely to be doing the heavy lifting in a business case somebody else wrote. The checks further down will tell you when they are.

The time to find it, the time to fix it, and whatever it costs downstream: a credit note, a second delivery, an apology from someone senior. Count what you would actually pay, not what a worst case would cost, and set it to zero if you have never measured it. A zero you can defend beats an estimate you cannot.

3. What the automation actually does

No automation covers every run, and the ones it does cover still need a person looking at the odd one. This is where an optimistic business case gets made, so these four fields carry most of the honesty on the page.

Reviewing an exception is usually slower per item than doing the task, because the person has to reconstruct what the machine was thinking before they can decide whether it was right. If your review time is shorter than your run time, be ready to say why. A residual error rate of zero is available in this field and is almost never true in production.

Look up your own vendor and model prices rather than trusting a figure from an article, including this one: they move, and token spend depends on what you send. Maintenance covers the API that changes shape, the credential that expires, the supplier who renames a column, and the person who has to notice.

4. What the build costs

Use a quote if you have one. If you do not, our own published bands are here as presets so the payback is measured against a real number rather than a round one.

This one does not change the payback. It sets the horizon for the spending ceiling in the results, which is the answer to the question you probably came here with: how much is it worth paying anyone to build this.

Our automation bands

Automation audit

One production workflow

The audit is a diagnostic, not a build. It tells you which of your processes is worth automating and what each would take, and it is credited against the work that follows. Putting $4,000 to $6,000 in the field above therefore prices the payback on finding out, which is a different question from the payback on the automation itself. One production workflow, built and running, is $12,000 to $25,000. Our minimum for a build is $7,500.

The bands above are estimates, shown in US dollars and drawn from comparable work already delivered, because no two projects carry the same scope. Your own quote is not an estimate: it is fixed in writing after scoping, before kickoff, and it does not move.

5. Three things the arithmetic cannot see

These change no number on this page, on purpose. They appear in the checks below as declared rather than measured, because applying a made-up discount factor to a payback figure would dress a judgement up as a calculation.

Invoice data entry, done by hand

$48,576 a year

$30,912 of labour and $17,664 of rework, across 3,680 runs and 736.0 hours a year.

Doing it by hand, per year
Runs a year4 people times 20 per week, over 46 working weeks.3,680
Hours a year3,680 runs at 12 minutes, divided by 60.736.0
Labour736.0 hours at $42 loaded.$30,912
Rework294.4 mistakes a year at $60 each.$17,664
Annual cost of doing it by hand$13.20 every time somebody runs it.$48,576
Owning the automation, per year
Runs it does not cover20% of runs, still done by hand: 147.2 hours at $42.$6,182
Exception review12% of the 2,944 automated runs, at 4 minutes each.$989
Mistakes that survive88.3 a year at $60, from the uncovered runs and from the 1% the automation gets wrong.$5,299
Model, vendor and hosting$150 a month, from the day it goes live.$1,800
Maintenance15% of a $18,000 build, a year, starting the month after launch.$2,700
Annual cost of owning it$4.61 every time it runs.$16,971
Annual saving$48,576 by hand, less $16,971 to own. Hours returned to the team: 565.2.$31,605

Payback on a $18,000 build

6.8 months

$18,000 divided by $2,634 of saving a month. Counted the other way, that is 2,096 runs of invoice data entry before the build has paid for itself.

Net position after year oneThe saving, less the build. Negative is normal in year one and is not by itself an argument against building.
$13,605
Net position after three yearsThree years of saving, less the build. Maintenance and vendor spend are already inside the saving, so this is not the same as multiplying a gross figure by three.
$76,816
The most this is worth paying forThe build cost at which payback lands exactly on your 12 month horizon. Maintenance is a share of the build, so this is not simply 12 months of saving: raising the build raises the annual cost of owning it, which is why the ceiling arrives sooner than division suggests.
$29,831

Conditions the payback figure depends on

9 checks ran against what you entered. None of them fired, which is the most this page can tell you: the arithmetic is not obviously resting on anything fragile.

  • It runs often enough for a build to amortise

    Held

    Rule: At least 250 runs a year.

    Yours: 3,680 runs a year.

  • It consumes enough of somebody's year to be worth removing

    Held

    Rule: At least 100 hours of manual time a year.

    Yours: 736.0 hours a year across 4 people.

  • It pays back inside a horizon anyone will wait for

    Held

    Rule: Payback within 18 months.

    Yours: 6.8 months.

  • It removes the work rather than moving it

    Held

    Rule: Residual manual time plus exception review below 50% of the manual hours.

    Yours: 23.2% of the manual hours survive, as 147.2 hours of untouched runs and 23.6 hours of exception review.

  • The case does not rest entirely on the cost of a mistake

    Held

    Rule: Rework below 60% of the annual manual cost.

    Yours: Rework is 36.4% of the manual cost, from 294.4 mistakes a year at $60 each.

  • The coverage assumption is not heroic

    Held

    Rule: Coverage at or below 90% of runs handled end to end.

    Yours: 80% of runs handled end to end, leaving 736.0 runs a year done by hand.

  • The process is not about to change

    Held (declared)

    Rule: You told us the process is stable for the next twelve months.

    Yours: You told us it is stable.

  • The constraint is the typing, not the decision

    Held (declared)

    Rule: You told us the slow part is the handling, not the judgement.

    Yours: You told us the slow part is the handling.

  • Somebody will own it after launch

    Held (declared)

    Rule: A named person or team is responsible for it in month thirteen.

    Yours: You told us there is a named owner.

When you should not believe the payback figure

A payback figure is easy to produce and easy to believe, which is a bad combination. Five things break one, and only two of them are visible in the arithmetic. The other three are judgements, and the calculator above marks them as declared rather than pretending to measure them.

It does not run often

A quarterly process gives an automation four chances a year to earn its maintenance, and thirteen weeks between runs for the world underneath it to move. By the time it runs again the credential has rotated, the export has a new column, and somebody is debugging on the day the report was due. Low frequency work is usually better served by a written checklist and a calendar reminder, which cost nothing to own and degrade gracefully.

It is about to change anyway

An automation is built against the shape of a process on one particular day: these fields, this system, this approval chain. If the ERP is being replaced next year, or the rule it encodes is under review, you are not buying a three year asset. You are buying a twelve month one at a three year price, and the payback figure above quietly assumed the longer life. The fix is not a bigger contingency, it is waiting, or building something deliberately disposable and pricing it that way.

The constraint is a decision, not the typing

This is the most common way a good automation delivers nothing. The task takes twenty minutes of handling and then sits in somebody’s queue for two days waiting for approval. Automate the twenty minutes and the cycle time falls by twenty minutes, which nobody notices, while the two days sit exactly where they were. The hours saved are real and the outcome does not move. If the reason a thing is slow is that a person has to think about it, the work is to remove the need for that thought, raise the threshold at which it is required, or delegate it, and none of those three is a build.

It needs more watching than the manual step did

The quiet failure. A person doing a task by hand notices when the input is wrong, because noticing is free and instant for a human holding the whole thing in their head. A machine does not notice, so somebody has to check, and checking a decision you did not make is slower per item than making it was. If the exception rate and the review time in the calculator push more than about half the manual hours back onto a person, you have not removed a task. You have converted it into queue monitoring, which is worse work at the same cost, and the people doing it will tell you so within a month.

The saving is really an estimate of a mistake

Hours are countable. The cost of a mistake usually is not, and it is the field where a business case gets whatever number it needed. When most of the annual saving comes out of the rework line rather than the labour line, the case is not measuring your process, it is quoting your own guess back to you at three decimal places. Halve the cost of a mistake and see whether the decision changes. If it does, go and measure the real figure before you spend anything, and if you cannot measure it, set it to zero and make the case on hours alone. A case that survives a zero there is a case you can defend in a room.

How to actually use this number

The output is not a budget and not a business case. It is a reference point you hold next to a proposal so the conversation stops being about whether a number feels big and starts being about which line you disagree on. That shift is the whole value of the exercise, and it is worth more than the payback figure itself.

Measure the process before you price it

Every number on this page is downstream of two inputs: how often the thing runs and how long it takes. Both are routinely wrong when people supply them from memory. Sit with one person, watch three real runs, and time them end to end including finding the file, waiting for the export and re-reading the last email in the thread. The figure you get is usually higher than the one people quote for the part they think of as the task, and lower than the one they quote for the part they resent.

Frequency is worse. A task that runs “every day” often runs on twelve days a month, and a task that runs “constantly” is frequently a hundred times a year. Count it from a system rather than from a person if any system can tell you: rows in a table, messages in a channel, tickets in a queue.

Take the spending ceiling more seriously than the payback

The most useful figure the calculator produces is the last one: the largest build cost that still lands inside the payback horizon you said you would accept. It answers a question a payback percentage cannot, which is whether to run this project at all and what it would be sane to pay.

If the ceiling is comfortably above the quotes you are looking at, the decision is easy and the remaining work is choosing a vendor. If it sits underneath all of them, no amount of negotiating gets you there, because the constraint is the process rather than the price. And if the ceiling is high because the rework line is high, go back and read the previous section before you act on it.

What to do when the payback is over two years

Do not compress the build to fix it. A cheaper build has the same running costs, a lower coverage figure and a higher exception rate, which moves the payback in the wrong direction while feeling like progress. Change the process instead.

The reliable moves are unglamorous. Cut the number of runs by batching, by validating at the point of entry so the rework never starts, or by deleting a step nobody defends. Raise the threshold at which an approval is needed. Merge two near-identical processes into one so a single automation covers both, which is usually the cheapest way to double the volume on a build you were already going to pay for. Each of those changes the inputs at the top of this page, and you can watch the payback move as you make them.

Where a diagnostic fits

If you have five candidate processes and no idea which one to start with, the answer is not to run this calculator five times on numbers you guessed. It is to measure them properly once. Our automation audit is $4,000 to $6,000 for exactly that: the processes measured, each one costed the way this page costs one, an order to do them in, and an honest list of the ones we would not touch. It is credited in full against the work that follows.

If you have already picked the process and just want it built, skip the diagnostic. One production workflow, live and maintained, is $12,000 to $25,000, and the arithmetic above will tell you before you call us whether that is a number worth spending on this particular task. We would rather you found out here. Both bands are estimates in US dollars, not quotations; the quote that follows scoping is fixed in writing before kickoff.

Keep reading

Bring us the process, not the pitch.

Send us the run count, the minutes and the numbers you got here. If the case does not hold we will say so on the call, which is cheaper for both of us than finding out in month four.

Talk to us about the processSee what automation work costs