How to Find What's Actually Worth Automating

Ask anyone who runs a business which parts of the week should be automated and you'll get an answer in about four seconds. Ask how many hours those parts actually cost, and the room goes quiet. That gap is the whole problem: the list everyone can name from memory is the list of things that are annoying, and annoying and expensive are not the same list.

We sell this work (Automation & Integration is one of our services), so read this as an explanation from an interested party. It's written to be useful even if you never contact us — the method below is one you can run yourselves in an afternoon.

Start with the week, not with the tools

Most automation projects start at the wrong end. Somebody sees a demo, buys a platform, and then goes looking for work to put through it. What follows is usually two or three automations that impress nobody, built around whatever the tool made easy rather than whatever the business was actually losing time to.

Start at the other end. Before any tool is chosen, before anyone says the word "integration", write down what your team does by hand. Not the job descriptions — the steps. "Sarah handles reporting" is not a step. "Sarah exports the sales figures, pastes them into a spreadsheet, reformats the columns the way the board likes them, and emails the file" is four steps, and they have very different automation stories.

The people who can give you this list are the people doing the work, not their manager. The interesting steps are the ones that never made it into any process document — the workaround, the second spreadsheet, the message someone sends to chase the thing that always gets forgotten. Managers describe the process as designed. The team describes it as run.

Write down four things per step

For every repeating step, capture exactly this:

• What it is, in the plainest language available. One sentence.
• Who does it. A named role, because "the team does it" hides the fact that three people all do their own version.
• How often. Daily, weekly, monthly, every time an order comes in, every time someone joins.
• How long it takes, honestly, including the part where you go and find the login.

Four columns. That's the whole instrument. Resist the urge to add a "priority" column filled in by feel — that's the thing you're trying to replace with arithmetic.

One warning on "how long": ask for the realistic figure, not the fast one. People estimate the version of the task where nothing goes wrong, and then do the version where the export times out and they start again. If your team says twenty minutes, the true number is usually the twenty minutes plus the two interruptions it takes to remember where they were.

Turn it into hours a month

Now multiply. Frequency times duration times the number of people who do their own copy of it. A step that takes forty minutes and happens twice a week is a little over five hours a month. A five-minute task that happens twenty times a day is nearly thirty-five hours a month, which is the one nobody nominates, because five minutes never feels like anything.

That reversal is the most common result of doing this properly. The task everybody complains about is often the one that happens monthly and takes an afternoon — genuinely irritating, roughly four hours a month. The task nobody mentions is the thirty-second lookup repeated all day by four people. The complaint list and the hours list are different lists, and only one of them is worth spending money against.

Sort by hours a month, descending. You now have something you didn't have before: an ordered list where the order came from arithmetic rather than from whoever complained most recently. That list is also the business case. You don't need a projection or a vendor's ROI calculator — you need the hours, and the hours are now written down.

Then subtract

Do not automate the top of that list yet. Four filters take things off it, and applying them is what separates a short list you'll actually keep from a long one somebody gets paid to build.

It doesn't happen often enough. Building, testing and maintaining an automation costs real time. A task that happens three times a year will never repay that, no matter how much everyone dislikes it. Write it down properly instead and move on.

It's about to change anyway. If the process is under review, or the system behind it is being replaced next quarter, you'd be automating a thing with a known expiry date. Wait.

The process itself is the problem. Some manual steps exist because two teams never agreed who owns something, so a person manually reconciles the disagreement every week. Automating that makes a broken agreement fail faster and further from anyone who'd notice. The honest fix is the conversation, not a workflow that hides it.

Nobody can reach the data. If the step depends on a system where you have no API, no export and no admin access — a vendor portal somebody logs into by hand, say — the automation question turns into a contract question first. Worth knowing before it becomes a surprise.

What survives all four filters is a genuinely short list. That's expected. A shorter list of automations you actually keep is worth more than a long one nobody maintains.

Rank what's left by two things, not one

Hours saved is the first axis. The second one is how bad the mistake is when a human gets it wrong.

Some manual steps are slow but harmless — if the weekly report goes out in the wrong font, nothing happens. Others are quick but carry real risk: retyping a figure into an invoice, setting up an account's permissions, copying an address into a shipping system. Those are worth automating slightly ahead of their hours, because you're buying accuracy as well as time. Every retype is a chance to fat-finger a number, and the cost of that isn't in the duration column.

So the build order is roughly: high hours, then high risk, then everything else. The first automation you build should be the single worst offender, done properly and documented, before anyone commits to a programme of work. If that one doesn't hold up, you've learned something cheap.

What this gets you before you spend anything

Run the exercise and you end up with three things: a list of what your business actually does by hand, an hours figure you can put in front of whoever approves spending, and a first automation chosen for a reason you can defend. All three are yours whether you build it in-house, buy a platform, or hire someone — and the same document tells you what the work should cost and whether a platform or something built is the right shape.

It's an afternoon's work with the right people in the room. If you'd rather not run it yourselves, that document is exactly what our free automation map is: five working days, we interview the people who do the work, and you get the inventory, the hours, the integration picture and the build order in writing. It's free and it's yours to keep, including the parts where it says a step isn't worth automating.

Either way, count the hours before you buy anything. Every automation decision after that one is easier, and the businesses that skip it are the ones who end up with a subscription, three workflows, and no idea whether it was worth it.