Registered office
20 Wenlock Road
London N1 7GU
A manual process is ready for automation when it is frequent, rule-based, measurable and understood well enough to describe its normal path, exceptions, inputs, owner and recovery route. If the process changes every week, depends on unrecorded judgement or produces unreliable data, improve it before automating it.
Reviewed: 9 September 2026
Automation readiness at a glance
| Signal | Ready to explore | Improve first |
|---|---|---|
| Volume | Repeated often enough to measure | Rare or unpredictable |
| Rules | Decisions can be stated and tested | Rules live only in individual judgement |
| Data | Inputs are structured and reasonably accurate | Missing, duplicate or inconsistent inputs |
| Exceptions | Known and routed to a person | Every case becomes a special case |
| Ownership | One person owns outcome and controls | No owner or competing definitions of success |
Good business process automation examples
Promising candidates include routing approved enquiries into a CRM, notifying a team when stock reaches a threshold, preparing joiner tasks after authorised approval, reconciling standard order data, creating scheduled operational reports and escalating overdue service requests.
The value is not “using automation”. It is reducing wait time, re-keying, preventable errors or missed controls while preserving appropriate human decisions. A small workflow that saves several people ten minutes every day may have more value than an impressive but rarely used system.
Observe the current process before redesigning it
Follow real work from trigger to outcome. Record who touches it, which systems are used, how long work waits, where data is copied and what happens when information is missing. Interviewing the process owner is useful, but observing examples often reveals hidden steps and unofficial workarounds.
Microsoft’s process-mining guidance explains how recorded activity can help identify repetitive work and visualise process steps. Use tools proportionately and tell staff what is being observed.
Measure the opportunity honestly
Establish a baseline:
- cases per day, week or month;
- active handling time and waiting time;
- error, rejection and rework rates;
- financial or service impact of delay;
- number and type of exceptions;
- control failures or missing evidence;
- staff and customer frustration.
Then define a realistic target. Time “saved” only creates value when the capacity is put to useful work or a genuine bottleneck is removed.
Simplify before you automate
Remove duplicate approvals, unused fields and avoidable hand-offs. Give each data item a source of truth. Standardise labels and define which cases legitimately need human judgement. Automating every historical step can make a poor process faster, less visible and harder to challenge.
Ask whether configuration in an existing product solves the problem. If not, compare integration, low-code and custom options using the low-code versus custom software guide.
Keep humans around consequential decisions
Automated decisions involving people, personal data or significant outcomes need careful governance. Document the purpose, data, logic, review and challenge route. The ICO’s current automated decision-making guidance is under review following legislative change, so check the live guidance and take appropriate legal or data-protection advice.
Even ordinary workflow automation needs a human exception queue. Silence is not proof of success: a failed connector may stop work without creating an obvious error.
Design for failure and change
For every automated step, define:
- how the action is authenticated and authorised;
- what is logged without exposing unnecessary sensitive data;
- how duplicates and retries are handled;
- who receives a useful failure alert;
- how a person resumes or corrects the case;
- what happens when a supplier, field or rule changes;
- how the workflow is tested and retired.
A workflow without monitoring and ownership is merely an invisible manual problem waiting to happen.
Run a bounded automation pilot
- Select one stable process and a representative group.
- Record the baseline and desired outcome.
- Map normal, exception and recovery paths.
- Automate the smallest valuable section.
- Run it alongside controlled checks long enough to collect evidence.
- Review errors, user effort, time and operational ownership.
- Scale, revise or stop based on evidence.
ACA’s discovery workshop for software and automation can turn an observed process into options, risks and a buildable first step.
How to build a simple automation business case
Compare the current annual handling and error cost with discovery, implementation, licences, support and change. Include qualitative benefits such as faster response or better audit evidence, but label assumptions. Show a low, expected and high case rather than one falsely precise payback date.
Revisit the case after the pilot. Real usage may reveal that the process volume, exception rate or support burden differs from the estimate. That learning is valuable even if the sensible decision is not to automate further.
Frequently asked questions
Should we automate a process that only one person understands?
First document and test that person’s decisions. Automation built around undocumented knowledge can hide errors and create a new single point of failure.
Does automation require artificial intelligence?
No. Many valuable automations use deterministic rules, integrations and notifications. Use AI only where it fits the evidence, risk and review model.
What is the best first automation?
Choose a frequent, stable, low-to-moderate-risk process with measurable effort and manageable exceptions. Avoid making the first pilot the most critical workflow in the company.
When should an automation be retired?
Retire or redesign it when the underlying process disappears, ownership is lost, errors outweigh value, the platform becomes unsupported or a standard product now solves the need better.
