Process to Automate First: Proven Way to Avoid Costly Risk

Process to automate first, tool second — that ordering is the whole difference between an automation programme that compounds and one that quietly dies after a single disappointing pilot. Most organisations get it backwards. They buy a platform, run a proof of concept on whatever process the vendor demonstrates well, and then spend a year explaining why the savings never appeared in a budget line.

The choice is not a technical one. Picking the right process to automate is a commercial and operational judgement about volume, variability, ownership and blast radius, and it can be made properly in about three weeks with a spreadsheet and a handful of interviews. This guide is the method: what a good candidate looks like, what disqualifies one instantly, where to find them, how to score them against each other, and how to prove the winner actually worked. It is written for mid-sized UK organisations spending their first serious money on business process automation, not for vendors trying to close a deal.

One framing note before the detail. Your first automation is not really a productivity project — it is a credibility project. It buys, or destroys, the organisational permission you need to do the next ten. Our workflow automation and intelligent automation work shows the same pattern year after year: the teams that scale are the ones whose first choice was boring, well-understood and impossible to argue with, not the ones whose first choice was ambitious.

If you already have a shortlist and want the money side, pair this with our automation ROI calculator; if you are still deciding between tool categories, start with workflow automation vs RPA vs AI agents.

Table of contents

Why the first process to automate sets the ceiling for everything after
What a good process to automate actually looks like
The five disqualifiers that rule a process to automate out immediately
Where to find every candidate process to automate
How to score every candidate process to automate
Sizing the process to automate: volume, handling time and error rate
Feasibility checks before you commit to a process to automate
Risk tiers: what happens when a process to automate goes wrong
Choosing technology only after choosing the process to automate
Worked example: twenty candidates, one process to automate
Proving the process to automate worked: baselines and measurement
Common mistakes when picking a process to automate
A 90-day plan for your first process to automate
Choosing the second and third process to automate
Frequently asked questions about choosing a process to automate
References

Why the first process to automate sets the ceiling for everything after

The first automation is measured differently from every one that follows. Nobody remembers the technical architecture; everybody remembers whether it worked and whether the people affected still speak to the project team.

The credibility budget

Every organisation extends a fixed amount of goodwill to a new initiative. A first process to automate that saves eleven hours a week on an unglamorous reconciliation task spends almost none of that goodwill and returns interest on it. One that half-works on a customer-facing process spends all of it in a fortnight. Choosing the first process to automate is really the act of deciding how much credibility you are willing to gamble, and the answer should be very little.

What a bad first choice actually costs

The direct cost is the wasted build effort, which is rarely the painful part. The real cost is the eighteen-month freeze that follows: a failed pilot hands every sceptic in the organisation a permanent argument, and the next business case has to clear a bar the first one never faced. We have seen programmes lose two years to a badly chosen first process to automate that would have been a footnote if it had been the fifth.

Why the second attempt is harder than the first

After a failure, the scrutiny is asymmetric. Your assumptions get challenged line by line, the finance team wants evidence rather than estimates, and the operational staff who lost time to the first attempt are no longer volunteering. None of that scrutiny is unfair — it is just expensive, and it is entirely avoidable by picking a first process to automate that cannot really fail.

The pattern in organisations that get this right

The teams that scale automation successfully almost always started somewhere unfashionable: invoice matching, starter and leaver access requests, weekly report assembly, licence reconciliation. The work was dull, the rules were written down, and the person who owned it was delighted to be rid of it. That is the shape you are looking for.

Why first automation attempts stall (UK mid-market programmes we have reviewed)

Process was changing during the build 31%

Exception rate far higher than assumed 27%

No single owner to sign off the rules 19%

Source system replaced mid-project 14%

Benefit was a headcount nobody would cut 9%

What a good process to automate actually looks like

There is a recognisable shape to a strong process to automate, and it has almost nothing to do with how annoying the work currently feels. Five properties do most of the assessment for you.

It runs on rules, not judgement

If a competent new starter could be handed a one-page instruction sheet and produce the same output as the person who has done the job for six years, the process is rule-based. If the experienced person makes calls that they cannot fully explain, you are looking at judgement, and judgement is expensive to encode. The best process to automate first is one where the rules already exist in writing somewhere.

The inputs arrive in a predictable form

A process to automate that is fed by a fixed report, a database query or a structured form is tractable. One fed by whatever a supplier decided to put in an email this month is not, at least not for a first attempt. Input variability, far more than process complexity, is what turns a four-week build into a four-month one.

It is digital from end to end

Any step that requires someone to physically sign, scan, post or walk something to another desk breaks the chain. You can automate around such a step, but every handover you engineer adds fragility. For your first process to automate, insist that the whole path lives inside systems you already run.

The volume is high and the variety is low

Volume creates the benefit; variety destroys it. Two thousand transactions a year that all look alike is a far better proposition than twenty thousand that fall into forty categories. A useful rule of thumb: if more than one in five cases needs a human decision, the case for treating it as your first process to automate weakens sharply.

Somebody owns the outcome and will admit it

Every strong candidate has a named person who is accountable for the output, can approve a change to the rules without convening a committee, and will personally benefit from the time saved. Where ownership is diffuse, the sign-off cycle alone can outlast the build.

Property	Strong signal	Warning signal
Rules	Written procedure exists and is followed	“It depends” is the most common answer
Inputs	Structured file, form or database record	Free-text email, scanned PDF, phone call
Path	Entirely inside existing systems	Wet signature, post, physical handover
Volume	Over 500 cases a year, steady	Seasonal spike, then nothing
Variety	Under 20% need human judgement	Over 35% are exceptions
Ownership	One named accountable person	Shared across three departments
Stability	Unchanged for 12 months or more	Under review or mid-restructure

The five disqualifiers that rule a process to automate out immediately

Scoring models are useful, but some conditions should remove a process to automate from consideration before it ever reaches the spreadsheet. Treat these five as hard gates rather than as scored criteria.

The process is about to change

If the department is mid-restructure, the regulation is under consultation, or a new system goes live within nine months, do not automate it now. You will build to a specification with a known expiry date, and the rebuild will cost more than the original.

Nobody will own the rules

Automation forces decisions that people have been comfortably avoiding. When you ask what happens if the value is negative, somebody has to answer definitively. If no single person has the authority to give that answer, the build will stall in exactly the place the manual process quietly muddled through.

The exception rate is above a third

A process where more than roughly 35% of cases need human intervention will not deliver much. You automate the easy two-thirds, the humans keep the hard third, and the context-switching cost of moving between the two often eats most of the gain. Fix the exception rate first, or choose a different process to automate.

It depends on a system you are replacing

Building against an application that is scheduled for replacement is the most avoidable mistake on this list, and it happens constantly because the automation team and the platform team do not talk. Check the roadmap before you check anything else — our note on data migration planning covers why those dates move.

The only benefit is headcount you will not remove

If the entire business case rests on removing 0.6 of a full-time role, and everybody knows that person will not be made redundant, the benefit is not real in cash terms. It may still be real as capacity — but say so explicitly, and value it as capacity, not savings.

Where to find every candidate process to automate

A good process to automate is rarely the one people nominate in a workshop. Nominations skew towards whatever is most irritating this week, which is not the same as whatever is most automatable.

Start with the ticket queue

Your service desk is the single best source of candidates in most organisations, because it is already instrumented. Export twelve months of tickets, group by category, and sort by count multiplied by median resolution time. The top ten rows of that table are a better list of candidate processes to automate than any workshop will produce, and every row comes with a volume figure attached.

Look at month-end

Period-close is dense with repetitive, deadline-driven, rule-based work: reconciliations, accruals, intercompany matching, report assembly. It is also visible to finance, which makes the benefit easy to verify. The constraint is timing — a monthly process gives you only twelve observations a year, which slows down measurement.

Mine the shared mailboxes

A shared inbox handling several hundred structured requests a month is an automation candidate wearing a disguise. The requests are usually more consistent than anyone believes, and the triage work is pure overhead. Sample two hundred messages and categorise them before deciding.

Follow the spreadsheets that get emailed

Any spreadsheet that is exported from one system, edited, and re-imported into another is a process to automate hiding in plain sight. These are extremely common, entirely invisible to management, and often the cleanest wins available. Ask people what they download every week.

Check onboarding and offboarding

Starter and leaver processes touch several systems, run on strict rules, carry real cybersecurity consequences when they are done late, and have an obvious owner in HR or IT. They are a common and defensible first choice.

Do not run an all-department idea workshop

Open nomination sessions generate long lists dominated by the loudest departments and by processes whose real problem is a policy, not a lack of automation. Use data first; use workshops afterwards to validate the shortlist you already have.

How to score every candidate process to automate

Once you have fifteen to twenty-five candidates, you need a way to compare them that survives contact with a room full of stakeholders. A weighted score identifies the best process to automate defensibly; a debate does not.

Why a scoring model beats a debate

A scoring model shifts the argument from “which process should we do” to “is this a 3 or a 4 on feasibility”, which is a far more productive disagreement. It also produces a written record of why the losing candidates lost, which you will need in three months when someone asks again.

The seven criteria

Score each candidate process to automate from 1 to 5 on annual volume, hours consumed, rule clarity, input structure, system accessibility, error impact and owner engagement. Seven is enough to be discriminating without becoming a modelling exercise in its own right.

How to weight them

Weight feasibility criteria higher than benefit criteria for your first automation, which is the opposite of what most people expect. A modest benefit you can definitely deliver beats a large one you might. From the third or fourth process onwards, shift the weights back towards benefit.

Score it in a room, not a spreadsheet

Circulate the rubric in advance, then score live with the process owners present. Disagreements of two points or more are the valuable output — they almost always reveal that two people believe different things about how the process actually runs.

The threshold rule

Set a minimum on feasibility, not just on the total. A candidate scoring 5 on volume and 2 on system accessibility will average well and still be a poor choice. Any process to automate scoring below 3 on either rule clarity or system accessibility should be excluded regardless of total.

Criterion	Weight	Score 1	Score 3	Score 5
Annual volume	15%	Under 200	500 to 2,000	Over 5,000
Hours consumed	15%	Under 100/yr	300 to 600/yr	Over 1,000/yr
Rule clarity	20%	Tacit knowledge	Partly documented	Written and followed
Input structure	15%	Free text or scans	Semi-structured	Structured data
System access	20%	No API, no export	Export only	Documented API
Error impact	10%	Customer or regulator	Internal rework	Caught next step
Owner engagement	5%	Unidentified	Cooperative	Actively sponsoring

Sizing the process to automate: volume, handling time and error rate

Three numbers decide whether a process to automate is worth building, and all three are routinely guessed rather than measured. Spend a week establishing them properly and your business case stops being an argument.

Count the volume from a system, not from memory

Ask how many times a month a process runs and you will get a number that is wrong by a factor of two in either direction. Pull it from the ticket system, the ledger, the mailbox export or the application log. Where no system holds the count, that absence is itself a finding about how automatable the process is.

Measure handling time by observation

Self-reported handling times are inflated by interruptions and deflated by pride, roughly cancelling out into meaninglessness. Sit with two people, time twenty cases each, and record the median rather than the mean — the mean will be dragged around by the one case that took ninety minutes.

Establish the error and rework rate

The error rate is usually the strongest part of the benefit and the least measured. Count how many cases come back, how long each takes to correct, and what the downstream consequence is. Reducing rework often justifies a process to automate on its own, before a single hour of handling time is counted.

Put the three numbers together

Annual volume multiplied by median handling time gives gross hours. Add rework hours. Multiply by a fully loaded hourly cost — not salary, which understates by roughly 30% — and you have the gross annual benefit against which to compare a build estimate.

Sanity-check against comparable processes

If your number implies a saving larger than the total salary cost of the team performing the work, you have made an arithmetic error. This check catches more inflated business cases than any review meeting.

Annual hours consumed — six shortlisted candidates at a 340-person distributor

Supplier invoice matching 1,180 hrs

Starter and leaver access setup 740 hrs

Weekly stock report assembly 520 hrs

Customer credit checks 410 hrs

Delivery note filing 290 hrs

Quarterly price list updates 160 hrs

Feasibility checks before you commit to a process to automate

Benefit tells you whether a process to automate is worth the money. Feasibility tells you whether you can actually build it, and it is where first-time programmes are most often wrong.

Interfaces and integration points

For every system in the path, establish whether there is a documented API, a supported export, or neither. “Neither” does not rule the process out, but it moves you into screen-level automation, which is more brittle and more expensive to maintain. Confirm this with the vendor in writing, not with an optimistic assumption.

Structured versus unstructured input

Extracting fields from a consistent supplier file is a solved problem. Extracting them from four hundred differently formatted PDFs is a machine learning project wearing the costume of an automation project. Be honest about which one you have before you commit to a delivery date.

Authentication, licensing and access

Service accounts, multi-factor exemptions, API rate limits and per-seat licensing rules routinely delay automation projects by weeks. Raise them in week one. A licence model that charges per automated action can invert the business case entirely, and you want to discover that early rather than at contract signature.

Data quality underneath the process

Automation removes the human who was silently correcting bad reference data. If supplier names are inconsistent or product codes are duplicated, the automation will fail loudly on cases a person handled without comment — which is why a data quality assessment belongs before the build, not after.

Estimate the build honestly

Take your first estimate of build effort and add the discovery, testing, documentation and handover you did not count. For a moderately complex first process to automate, fifteen to forty days of specialist effort is the realistic range, and internal effort counts as cost even when the budget pretends otherwise.

Risk tiers: what happens when a process to automate goes wrong

Every automation will get something wrong eventually. The question is what happens next, and for the first process to automate the answer should be reassuringly boring.

Blast radius

How many cases can be processed incorrectly before somebody notices? A process that runs once a month with a human reviewing the output has a blast radius of one cycle. A process that runs continuously against customer records has a blast radius measured in thousands. Choose the former first.

Reversibility

Can a wrong outcome be undone cleanly? Posting an incorrect journal is reversible; emailing an incorrect statement to two thousand customers is not. Reversibility matters more than error rate, because a reversible mistake is an inconvenience and an irreversible one is an incident.

Regulatory and personal-data exposure

If the process handles personal data, automating it changes the processing description and may require a fresh assessment under UK GDPR. That is manageable, but it is a work item with a lead time. Processes with no personal data and no regulatory reporting are meaningfully cheaper to automate first.

Where the human stays in the loop

Decide deliberately which decisions keep a person. Approving a payment above a threshold, releasing a customer communication and overriding a rule are all sensible places to retain review, and the pattern is well covered in our guide to human-in-the-loop AI workflows.

Monitoring from day one

An automation nobody watches is a liability. Decide before the build what will be logged, what threshold triggers an alert, and who receives it. This is ordinary IT operations discipline, and skipping it is how a small failure becomes a three-week backlog.

Risk tier	Typical process	Control required	First project?
Low	Internal report assembly, data copying	Output log, weekly spot check	Ideal
Moderate	Invoice matching, access provisioning	Exception queue, approval above threshold	Good
Elevated	Credit decisions, pricing changes	Human review of every case	Later
High	Customer communications, payments out	Dual control, full audit trail	Not first
Regulated	Statutory reporting, personal data at scale	Impact assessment, documented oversight	Not first

Choosing technology only after choosing the process to automate

Tool selection is easy once the process to automate is fixed, and nearly impossible before it is. The shape of the work tells you which category fits.

Workflow and platform-native automation

If the process moves work between people with approvals and notifications, and the systems involved are ones you already license, native workflow tooling is almost always the cheapest and most durable answer. It is unglamorous and it survives upgrades.

Robotic process automation

RPA earns its place where a system has no usable interface and no realistic prospect of getting one — typically an older line-of-business application. It works, but treat it as a bridge with a maintenance cost, not a destination, because every screen change is a break.

Integration and API-first automation

Where documented APIs exist on both sides, a straightforward integration beats both of the above on reliability and running cost. This is the option most often overlooked because it sounds like development work rather than automation.

AI agents and document understanding

Language models genuinely change what is feasible for unstructured input and for processes with long-tail variation, and our AI employees and autonomous agents practice deploys them where that fits. They are the wrong choice for a first project, because they add evaluation, monitoring and failure modes you have not yet built the muscles for.

The rule to hold on to

Pick the least capable technology that comfortably handles the process you selected. Excess capability is not free — it is paid for in licensing, complexity and the skills you now have to keep in the building.

Process shape	Best fit	Typical build	Maintenance load
Approvals and handoffs	Native workflow tool	5 to 15 days	Low
System A to system B, APIs exist	Integration	10 to 25 days	Low
Legacy app, no interface	RPA	15 to 40 days	High
Structured documents at volume	Document capture	20 to 45 days	Medium
Unstructured text, long tail	AI agent with review	30 to 60 days	High

Worked example: twenty candidates, one process to automate

Abstract criteria are easy to agree with and hard to apply. Here is the whole method run end to end at a 340-person distribution business with no prior automation, from longlist to a single chosen process to automate.

The longlist

Twelve months of service desk tickets, a finance month-end walkthrough and two shared mailbox exports produced twenty-three candidates. Nine were removed immediately against the disqualifiers: four depended on an ERP being replaced the following spring, three had no identifiable owner, and two had exception rates above 40%.

The shortlist and the scores

The remaining fourteen were scored against the seven criteria. Six cleared the feasibility threshold. Supplier invoice matching led on volume and hours; starter and leaver access setup led on rule clarity and owner engagement; weekly stock report assembly was the cheapest to build by a wide margin.

The winner, and why it was not the biggest

Invoice matching consumed the most hours but scored 2 on system access — the finance system exposed no API and the supplier portal changed layout regularly. Starter and leaver access setup won: 740 annual hours, fully documented rules, structured HR system input, an enthusiastic owner in IT, and a moderate risk tier with an exception queue. It was the second-largest benefit and by some distance the safest process to automate first.

What happened next

The build took nineteen days. Median provisioning time fell from 2.4 days to 40 minutes, the access-rights audit stopped finding orphaned accounts, and the IT manager who owned it became the programme’s most effective advocate. Invoice matching was automated eleven months later, once the finance system upgrade delivered the API.

The lesson worth stealing

The largest benefit on the list was the wrong first choice, and the scoring model is what made that visible before anybody had committed a budget. Had the decision been made in a workshop, invoice matching would have won on volume alone and the programme would have spent six months fighting a portal.

Weighted scores of the six shortlisted candidates (out of 5)

Starter and leaver access setup 4.35

Weekly stock report assembly 4.05

Supplier invoice matching 3.40

Quarterly price list updates 3.10

Customer credit checks 2.85

Delivery note filing 2.40

Proving the process to automate worked: baselines and measurement

A process to automate that cannot be shown to have worked is indistinguishable from one that did not. The measurement plan belongs in the selection phase, not the closing report.

Baseline before you build

Record the current cycle time, error rate, volume and cost while the process is still manual. Once the automation is live, the old numbers are gone and every claim you make becomes an assertion. Two weeks of baseline data is the cheapest insurance in the whole project.

Define success in advance and in writing

Agree the target with the process owner and the finance sponsor before the build starts: cycle time under X, exception rate under Y%, no increase in downstream corrections. Vague success criteria are how projects get declared complete without anybody believing them.

Instrument the automation itself

Log every run, every exception and every manual intervention. The intervention count is the number that matters most — an automation requiring daily human rescue has not saved anything, and only instrumentation will tell you that honestly.

Review at 30, 60 and 90 days

Early reviews catch specification gaps while they are still cheap. The 90-day review is the one that decides whether the process to automate you chose was the right one, and whether the same method should pick the next.

Report in the sponsor’s language

Convert hours into either cost avoided or capacity redeployed, and say which. Finance teams distrust automation benefits precisely because programmes keep reporting hours as if they were cash. Being explicit about the difference buys you far more credibility than a bigger number would.

Common mistakes when picking a process to automate

The same errors recur across organisations of every size, and all five are avoidable with a week of discipline applied before anybody chooses a process to automate.

Choosing the most painful process

Pain and automatability are only loosely correlated. The most hated process in the building is frequently hated because it is ambiguous, contested and full of exceptions — which is exactly what makes it a poor first choice.

Choosing the most visible process

A customer-facing process gets attention, which is precisely the problem. Visibility raises the cost of failure without raising the benefit. Earn the right to touch the visible processes by succeeding on an invisible one.

Letting the vendor choose

Vendors demonstrate what their product does well. That demonstration is useful information about the product and no information at all about your priorities. Choose the process to automate first, then run a procurement — our AI procurement checklist covers the questions worth asking.

Automating a broken process

Automation makes a process faster and more consistent; it does not make it correct. If the underlying design is wrong, you will produce wrong outcomes at a higher rate. Simplify first, automate second — and be prepared to discover that the simplification alone captured most of the benefit.

Starting six at once

Parallel pilots feel efficient and are not. They split scarce specialist attention, and when results are mixed nobody can tell what caused the difference. One process to automate, done properly, teaches you more than six done partially, and the change management load of six simultaneous changes is what usually breaks first.

A 90-day plan for your first process to automate

Selection does not need to take a quarter, but it does need to be deliberate. This is a realistic sequence from a standing start to a live process to automate and a decision you can defend.

Days 1 to 15: gather candidates from data

Export ticket data, walk through month-end, sample two shared mailboxes, and interview six people about what they download every week. Produce a longlist of fifteen to twenty-five candidates with a one-line description each. Resist the urge to evaluate anything yet.

Days 16 to 30: apply the disqualifiers and score

Run the five hard gates, then score the survivors with the owners in the room. Publish the scores, including the losers and the reasons. This document does more to protect the programme later than any steering committee paper.

Days 31 to 45: baseline and design

Measure the winner properly, write the rules down as a specification the owner signs, and confirm the interfaces exist as claimed. Any nasty surprise found here is worth ten found during the build.

Days 46 to 75: build and test with real cases

Build against the specification and test with a hundred real historic cases, not invented ones. Historic cases contain the exceptions your interviews missed, and they are the difference between a demo and a working process.

Days 76 to 90: pilot in parallel, then decide

Run the automation alongside the manual process for two to three weeks and compare outputs case by case. At day 90, hold a genuine go or no-go review against the success criteria you wrote on day 30, and be willing to say no.

Choosing the second and third process to automate

The method that picked your first process to automate is not quite the right method for the ones that follow, and the difference is worth understanding before you reuse the rubric unchanged.

Favour reuse over novelty

The cheapest second process is the one that reuses the connectors, patterns and approvals you already built. A slightly smaller benefit delivered in eight days beats a larger one that starts from scratch — this is the same compounding logic behind an infrastructure as code business case.

Shift the weights towards benefit

Once you have delivered twice and the organisation trusts the team, you can afford more ambitious candidates. Move weighting away from feasibility and towards annual hours and error impact, and let the elevated risk tiers back into scope with appropriate controls.

Keep the pipeline visible

Maintain the scored longlist as a living document and re-score it every six months. Processes move: a system upgrade can turn an infeasible candidate into an obvious one, and a restructure can do the reverse.

Know when to stop

Not every process should be automated. When the remaining candidates all score below three, the honest answer is that the backlog is exhausted for now, and the effort is better spent on cost optimisation or on improving the processes themselves. Programmes that cannot say this end up automating work that should simply have been deleted.

Frequently asked questions about choosing a process to automate

How long should it take to choose a first process to automate?

Three to four weeks of part-time effort is normal and sufficient. Longer than six weeks usually means the organisation is trying to reach consensus rather than make a decision, and the extra time buys nothing.

Should the first process to automate be in IT or in the business?

Either works, but the process needs a business-side owner who benefits from the outcome. IT-owned processes are often easier technically and harder to claim benefit for, because the saved time is absorbed rather than visible.

What if two candidates score identically?

Choose the one with the smaller blast radius, then the one with the more engaged owner. For a first project, safety and sponsorship beat marginal benefit every time.

Is a process with 25% exceptions worth automating?

Usually yes, provided the exceptions route cleanly to a person and the automation handles the remaining 75% without supervision. Above roughly 35%, the economics deteriorate quickly.

Do we need a formal business case for the first one?

Yes, but a short one. A single page with the three sizing numbers, the build estimate, the success criteria and the risk tier is enough, and it is what makes the 90-day review meaningful.

What is the most common reason a first automation disappoints?

Undercounted exceptions, by a wide margin. The interviews describe the happy path; the historic case sample reveals the truth. Test against real history before you commit.