How Do You Calculate the ROI of Automating a Task in a Small Team?

## The short answer

To work out whether automating a task pays off, calculate the annual cost of doing it manually (time per run × runs per year × the loaded hourly cost of whoever does it) and subtract the cost of building and maintaining the automation. If the manual cost meaningfully exceeds the automation cost over a sensible horizon — usually a year — it's worth doing. The catch most small teams miss: time saved only counts as ROI if it gets reinvested in something valuable, not absorbed back into the day.

## The basic formula

Start with the manual cost:

- **Time per run**: how long the task takes once, end to end, including the faff of switching tools.

- **Runs per year**: weekly frequency × 52, or however often it genuinely occurs.

- **Loaded hourly cost**: the person's salary plus overheads, divided by working hours. Use a loaded figure, not just base pay — it's a truer picture of cost.

Manual annual cost = time per run × runs per year × loaded hourly cost.

Then the automation cost:

- **Build time**: hours to design, build, and test it, at the builder's loaded rate.

- **Maintenance**: an honest annual estimate for fixes when tools change or edge cases appear.

- **Tooling**: any subscription or licence the automation depends on.

If manual annual cost comfortably exceeds build plus first-year maintenance plus tooling, you have a case.

## Don't forget the hidden returns

Pure time saved understates the value. Automation also tends to:

- **Reduce errors.** A mistyped figure or missed follow-up can cost far more than the minutes saved. Fewer errors means less rework and fewer unhappy customers.

- **Improve consistency.** Every customer gets the same response time and the same quality, which protects your reputation.

- **Remove key-person risk.** When a process lives in one person's head, you're exposed if they're off or leave. Automation documents and de-risks it.

- **Free attention, not just time.** Removing a nagging background task often improves the quality of the work that remains.

These are harder to put a number on, but they're real. A useful habit is to note them qualitatively alongside the hard numbers so they're not ignored.

## The trap: phantom time savings

Here's where small teams fool themselves. You automate something that saved each person ten minutes a day. Across the team that's a few hours a week — on paper. But ten minutes here and there rarely converts into a meaningful block of productive time; it gets swallowed by context-switching and other small tasks.

Time savings are most real when they're **concentrated** (a two-hour weekly report becomes five minutes) or when they **remove a bottleneck** (a task that held up other work). Scattered minutes are nice for morale and error reduction, but be honest about whether they translate into capacity you can actually use elsewhere.

## A worked way of thinking about it

Imagine a weekly report that takes someone ninety minutes. That's roughly 78 hours a year. At a loaded hourly cost, that's a real annual figure. If automating it takes, say, a couple of days to build and a few hours a year to maintain, the payback period is short and the ongoing return is strong — especially because the time saved is concentrated and the report is error-prone when done by hand.

Now contrast that with automating a task that takes two minutes and happens five times a week. That's under nine hours a year. Unless it's error-prone or blocks something important, the build and maintenance may never pay back. Same effort, very different return.

## Account for maintenance honestly

The most common reason an automation's ROI disappoints is underestimated maintenance. Tools update, APIs change, edge cases surface. A reasonable rule of thumb is to assume ongoing upkeep is a non-trivial slice of the original build effort each year. If a task is so marginal that it only pays back when you assume zero maintenance, treat that as a signal to leave it manual.

## When the numbers say no

Sometimes the maths says don't automate — and that's a perfectly good answer. Low-frequency, high-judgement tasks are often better left to people. Documenting them well, with a clear checklist, can capture most of the consistency benefit without the build and maintenance burden. Automation is a tool, not a goal.

## Practical takeaway

For any task you're tempted to automate, write down four numbers: time per run, runs per year, loaded hourly cost, and honest annual maintenance. Favour tasks where the saved time is concentrated or removes a bottleneck, and where errors are costly. If the payback is over a year on optimistic assumptions, leave it manual and write a good checklist instead.