What to automate first · Clarke Systems Group

Most operations teams have more candidates for automation than they have time to assess. The usual result is that the loudest process gets picked, not the best one. A short, honest scoring exercise fixes that. It takes an afternoon, needs nothing more than a spreadsheet, and gives you a ranked list you can defend.

Signs a process is ready

Good first candidates share a recognisable profile. Look for processes that are:

High volume. The same task happens many times a day or week, so small savings per item add up.
Repetitive. Each case follows broadly the same steps as the last.
Rule-based. You can write down how decisions are made. If a new starter could follow a checklist, a system can too.
Stable. The steps have not changed materially in months and are not about to.
Digital already. The inputs arrive as emails, spreadsheets, system exports or PDFs, not on paper.
Costly when wrong. A mistake means a credit note, a missed deadline, rework or an unhappy customer.

A process does not need every trait. But the more it has, the easier it is to build, test and trust.

Signs it is not ready

Some processes look like automation candidates and are not. Be wary when:

The process changes weekly, because the rules are still being worked out.
Every case needs real judgement, such as negotiation, a relationship call or an exception that is different each time.
The data lives on paper, in someone's head or in free-text notes nobody else can read.
Nobody can say who owns it.

None of these is permanent. A process that fails today may be a strong candidate once it settles or its data is captured properly. Park it and revisit it.

A simple scoring model

Put each candidate process on its own row in a spreadsheet. Then work through these steps.

Score hours per week, 1 to 5. 1 means under an hour across the team. 5 means more than a day of someone's time every week.
Score error cost, 1 to 5. 1 means mistakes are trivial and caught quickly. 5 means mistakes reach customers, finance or regulators.
Score rule clarity, 1 to 5. 1 means the decisions rely on experience. 5 means every decision could be written as a rule.
Score data readiness, 1 to 5. 1 means paper or inconsistent free text. 5 means clean, structured data in a system you can export from or connect to.
Score process stability, 1 to 5. 1 means it changes most weeks. 5 means it has been the same for a year.
Apply weights. Value matters most, so double the scores for hours and error cost. Keep the other three at single weight. The maximum is 35.
Apply a gate. Any process scoring 1 on rule clarity, data readiness or stability drops off the list for now, whatever its total.
Rank and sense-check. Sort by weighted total. Read the top three aloud to the people who do the work. If one surprises them, find out why before you go further.

The weights are a starting point, not a rule. If errors are your main pain, give error cost a heavier weight. What matters is that you apply the same weights to every process.

Estimating value honestly

A score tells you which processes look promising. It does not tell you what they are worth. For your top two or three, estimate annual value with this formula:

Annual value = (hours per week × working weeks × loaded hourly cost × share actually automated) + annual cost of errors avoided

Three terms deserve care. Loaded hourly cost is salary plus employer costs such as National Insurance, pension and overheads, divided by working hours. Share actually automated is rarely 100 per cent. Exceptions still need a person, and someone still reviews the output. Errors avoided should use incidents you can point to, not a guess at what might go wrong.

Worked example, using hypothetical round numbers: a team spends 6 hours a week on a process. Loaded cost is £25 an hour, over 46 working weeks. You expect 80 per cent of the work to be automated, with the rest handled as exceptions. That gives 6 × 46 × £25 × 0.8 = £5,520 a year in time. The team also records around 20 errors a year, each costing roughly £100 to put right. Adding £2,000 gives an annual value of £7,520.

If you want to test your own numbers quickly, the ROI calculator on our services page runs the time-saving part of this arithmetic, using 46 working weeks.

Estimating payback

Value means little without cost. Payback is the build cost divided by the monthly net value, where net value subtracts any ongoing support.

Continuing the hypothetical example: suppose the build costs £3,000 and support costs £200 a month. Annual net value is £7,520 minus £2,400, or £5,120. That is roughly £427 a month. Payback is £3,000 ÷ £427, or about seven months.

Use payback as a filter rather than a target. A process that only pays back after several years is rarely a good first project. Be conservative with every input. If the case only works with optimistic numbers, it is not a strong case.

Pick a first project you can finish

Your first automation has two jobs. It should save time, and it should prove to your team that automation works. The second job matters as much as the first.

So choose something small enough to finish in weeks, not months. A single report, one integration between two systems or one validation step is often enough. Most of our builds are scoped at two to six weeks. That is a useful benchmark for a first project. If your top-ranked process would take far longer, look for a self-contained slice of it, or take the second process on the list.

Make sure someone owns it. A process owner who can give one to two hours a week to answer questions and test the output is the difference between a system that goes live and one that stalls.

What to document before talking to anyone

Before you speak to a supplier or an internal team, write a one-page brief. It saves time on both sides and sharpens your own thinking. Cover:

Owner. Who is accountable for the process and can sign off changes.
Steps. What happens, in order, from trigger to finished output.
Volumes. How many items, how often, and how long each one takes.
Systems. Every tool, spreadsheet and inbox the process touches.
Exceptions. The cases that do not follow the normal path, and how often they occur.

With that page in hand, you can request a free demo and written plan built around your actual process.

Common mistakes

Automating a broken process. If the process is wrong, automation makes it wrong faster. Fix the steps first.
Starting with the biggest process. The largest process is usually the most complex and the slowest to deliver. Start smaller and build confidence.
No owner. Without one person accountable, questions go unanswered and testing slips.
No measurement. Record hours and errors before you start. Without a baseline, you cannot show what changed.

For examples of how this discipline applies at scale, see our track record.

Key takeaways

The best first candidates are high volume, rule-based, stable, digital and costly when wrong.
Score every candidate on the same five criteria, weight for value, and exclude any that fail on clarity, data or stability.
Estimate value with hours, loaded cost, a realistic share automated and documented error costs.
Check payback against build and support costs, using conservative inputs.
Choose a first project you can finish in weeks, with a named owner and a measured baseline.

Which processes should you automate first?