How to identify tasks in your business that should be automated

Start from cost, not from technology

The most common way to choose an automation target is to notice a tool that looks impressive and then look for somewhere to apply it. This produces systems that work correctly and change nothing.

The alternative is to start from where the business is actually paying. That cost usually appears in one of three forms: time spent repeating steps, revenue lost through delay, or errors that need correcting later. If a task does not clearly sit in one of those three, automating it is unlikely to pay back.

The five filters

Once a candidate task is identified, it needs to pass five filters. A task that fails any one of them is a poor first project—not necessarily impossible, but a bad place to start.

1. Repetition

   Does this happen often enough to matter? A task performed twice a week takes far longer to repay setup cost than one performed thirty times a day. Volume is usually the single strongest predictor of whether automation pays back.

2. Rules

   Can the decision be written down? If a person follows consistent, explainable logic, that logic can be implemented. If the answer is "it depends, you get a feel for it", the rules are not yet explicit enough to automate reliably.

3. Stability

   Has the process stayed roughly the same for the last few months? Automating a process that is still changing weekly means rebuilding it repeatedly. Stabilise first, automate second.

4. Data quality

   Are the inputs dependable? Automation applied to inconsistent inputs produces inconsistent outputs faster. If the source data is unreliable, fixing that comes first.

5. Exception handling

   When something unusual happens, can a person step in? Every real process has exceptions. A system without a path for them will either fail silently or make confident mistakes.

Where the value usually is

Across the projects delivered here, the tasks that repay automation fastest fall into a small number of recognisable patterns.

• Moving data between two systems that do not talk to each other—the same values typed twice
• Responding to incoming enquiries outside working hours, where delay directly costs revenue
• Extracting structured information from documents that arrive as PDFs, scans or photographs
• Routing incoming work to the right person based on rules that are already written down
• Producing the same recurring report from the same sources on the same schedule
• Chasing follow-ups that currently depend on someone remembering

Where automation usually disappoints

It is worth being equally clear about the patterns that tend to disappoint, because avoiding one bad project is worth more than adding a good one.

• Tasks requiring genuine judgement, negotiation or relationship context
• Processes that change substantially every few weeks
• Work with very low volume, where setup cost exceeds lifetime saving
• Anything depending on data nobody trusts—automation amplifies the distrust
• Steps that only exist because of an upstream problem that should be fixed instead

A simple way to run this yourself

You do not need a consultant to do the first pass. Over one week, ask the people doing the work to note any task they perform more than twice, along with roughly how long it took.

At the end of the week you will have a list. Sort it by total time spent, then run the top five items through the five filters above. Usually one or two candidates survive clearly—and those are your first project.

This exercise is deliberately low-tech. Its value is not precision; it is that it replaces opinion about where time goes with a record of where time went.

What to do with the result

Once you have a candidate, resist the urge to automate the whole process at once. Take the narrowest useful slice—one workflow, one channel, one document type—and implement that end to end, including the exception path.

A narrow system that runs reliably builds the confidence and the evidence for the next one. A broad system that half-works produces the opposite, and makes the next project harder to justify internally.

FAQ