Blog
Automation

Where automation actually pays off

Where automation actually pays off cover

Most automation conversations we have start the same way. Someone describes the job in their business that annoys them most, and asks whether we can make it go away.

Usually we can. The problem is that the job that annoys you most and the job that costs you most are almost never the same job. The annoying one is the thing you personally have to do at 6pm on a Friday. The expensive one is usually something quiet that four people spend thirty minutes on every single morning, and nobody complains about it because it has always been done that way.

We've built automation for energy companies, construction firms, property marketing agencies and events businesses. The pattern holds every time. So before you spend anything, it's worth working out which of your processes will actually pay you back.

Here's how we do it.

Count how often it happens before you count anything else

Frequency beats everything. A two hour job that happens once a quarter is eight hours a year. A four minute job that happens sixty times a day is over 200 hours a year. The four minute job feels trivial and the two hour job feels like a nightmare, but only one of them is worth paying to fix.

This is why the loudest complaint in a business is so often the wrong place to start. Loud problems tend to be rare and painful. Expensive problems tend to be small and constant.

So write down your candidate processes and put a number next to each one: how many times does this run in a week? Anything running daily or more often goes to the top of the list. Anything running monthly or less goes to the bottom, however much you hate it.

The four questions

Once you've got things ordered by frequency, we run each one through four questions.

How long does it take, start to finish? Not how long the typing takes. How long the whole thing takes, including the bit where someone waits for an email back, or opens a second system to check a number. Waiting time is real time and it's usually where most of the hours hide.

How many people touch it? A process that passes through three pairs of hands has three handover points where things get dropped, chased and re-explained. Processes with handovers almost always cost more than the people doing them think, because everyone only sees their own part.

How much does it vary? If the process runs the same way 95 times out of 100, automation works well. If every case is a bit different and someone has to make a judgement call each time, you're looking at a much harder and more expensive build. Not impossible, just different work.

What does it cost when it goes wrong? Some processes are just slow. Others are slow and dangerous. A mistake in a quote costs you margin. A mistake in a compliance record costs you a lot more than that. Errors that carry real consequences push a process up the list even if the time saved is modest.

Then do the maths roughly, on purpose

You do not need a spreadsheet model for this. You need a number that is roughly right.

Take the hours a year, multiply by a fully loaded hourly cost for whoever does the work, and you've got your annual cost. Say a job takes twenty minutes, runs four times a day, five days a week. That's about 350 hours a year. At £25 an hour that's £8,750 a year going into one process.

That's the number that matters. Not because the automation will recover all of it, because it very rarely does. Somebody still has to check the output, handle the odd exception and own the process. But if a process is costing you £8,750 a year and the automation costs a few thousand once, the answer is obvious. If it's costing you £900 a year, no amount of clever engineering will make that worth doing.

Be sceptical of anyone who gives you a precise projection here. We tend to assume automation removes 60 to 80 percent of the time on a well chosen process, and we'd rather be wrong on the low side.

What this looks like in real projects

Three of the projects we've delivered are useful examples of how differently this plays out.

For an energy company we automated the sales cycle. The individual steps were small and nobody thought of them as a problem. What made it worth doing was volume. The same handful of actions repeated all day, every day, across the whole team.

For a construction client we built a snagging and contractor management platform. The driver there was different. Snags were being recorded on paper and in photos on people’s phones, and the cost was not really the recording, it was the chasing and the arguments about what had been fixed. The error cost was doing the damage, not the time cost.

For a global events company we did CRM and sales automation. That one was about handovers. Information was moving between people and between systems, and every hop was an opportunity to lose something.

Same underlying method, three different reasons for the work to be worth doing. If you only look for time savings you'll miss two out of three.

What to leave alone for now

This is the part most people skip, so I'll be blunt about it.

Processes you're about to change anyway. If you're mid way through changing how your sales team works, do not automate the current version. You'll pay to build something and then pay again to unbuild it. Wait until the process settles.

Processes nobody owns. If you can't name the person responsible for a process, automating it will not help. It will produce output that nobody checks and nobody trusts, and within three months people will quietly go back to doing it by hand.

Low volume work, however irritating. Your annual insurance renewal is annoying. It is annoying for four hours a year. Leave it.

The judgement calls that are actually your product. Some of what your people do looks repetitive from the outside but is really expertise applied quickly. Automating it makes your output worse. Clients notice.

Anything sitting on data you don't trust. This one catches a lot of businesses out. If your customer records are half duplicated and your stock numbers are three days behind reality, automation will move bad data around faster. Fix the data first, or accept that fixing the data is the first half of the project.

The awkward middle

There’s a category between “do this now” and “leave it alone”, and it’s bigger than most people expect.

These are processes that are genuinely expensive but too messy to automate as they stand. The usual cause is that the process grew rather than being designed, so it has six steps that exist because of a decision somebody made in 2019 and nobody has revisited.

For these, the first job is not automation, it's simplification. Cut the steps that no longer make sense, then automate what's left. It's slower and less exciting, and it produces better results than building software around a bad process. We'd rather tell you that at the start than three months in.

Working out where you stand

If you've read this far you can probably already name two or three processes that belong at the top of your list. That's most of the value of doing this exercise.

If you'd rather do it with someone who's been through it before, our consultants walk through these same questions with you on a free 20 minute call. No deck, no pitch. You'll come out of it with a shortlist and a rough sense of what each one would cost to fix.

Our builds start at £7,900. Part of the reason we publish that number is so you can do the sum in this article yourself and work out whether it’s worth a conversation before you have one.

Frequently asked questions

How do I know if a process is too complicated to automate?

The test we use is variation. If the process runs the same way in more than about 9 cases out of 10, it automates well. If nearly every case needs a judgement call, the build gets much more expensive and the payback gets much slower. That doesn't rule it out, but it changes the conversation from weeks of work to months.

Should I automate one process or several at once?

One, almost always. Pick the highest volume process you can define clearly, get it working, and let people use it for a month before you add the next one. Businesses that try to automate five things at once usually end up with five things that half work and a team that has lost faith in the whole idea.

What if my data is a mess?

Then that's the first piece of work. Automation moves data around, so it inherits whatever quality problems your data already has. Sometimes the fix is small. Sometimes cleaning up and joining your systems together is genuinely the bulk of the project, and we'd tell you that up front rather than discover it later.

How long before an automation pays for itself?

For a well chosen process, we'd expect the time savings to cover the build cost inside a year. If our estimate says three years, we'll say so and suggest you spend the money elsewhere. The honest answer is that payback depends far more on picking the right process than on how well the automation is built.

Back to all posts