Questions we answerAI and automation
Is my process ready to automate?
Four things have to be true: the steps repeat, they are written down, it happens often enough to pay back, and someone can say what a failure costs.
Free · a few minutes · starts from “I think AI could help”
The short answer
A process is ready when four things are true: the steps are the same each time, they are written down accurately, it happens often enough that the build pays for itself, and someone can say what happens when it goes wrong. Miss the first and you will automate exceptions forever. Miss the second and you will automate the mess. Miss the third and the setup costs more than the work. Miss the fourth and you will discover how much a mistake costs after the first one, which is the expensive order.
Readiness is a more useful frame than desirability. Almost any repetitive process is desirable to automate; far fewer are ready, and the difference is where automation projects go wrong.
The four conditions below are not a maturity model. They are the specific things that, when absent, cause an automation to be abandoned within a year.
Is it really this?
Worth checking before you spend anything. These are the signals that tend to tell the two apart.
Signs it is
- Someone could hand the process to a new starter with a page of instructions.
- The exceptions are known and countable rather than endless.
- It runs often enough that a week of setup is obviously worth it.
Signs it's something else
- Every instance needs a judgement call that is hard to write down.
- The process changed twice this quarter and will change again.
- It is genuinely rare, and a checklist would do.
What's usually behind it
- A visibly repetitive process that feels overdue for automation.
- A tool purchase that has been approved before anyone established what it would run.
- A previous attempt that quietly stopped being used, without anyone diagnosing why.
What people usually get wrong
- Automating the happy path and handling the exceptions manually forever, which is most of the work.
- Skipping the question of what a failure costs, and finding out in production.
- Building alongside a system you already pay for that could have done most of it.
The options, and when each one fits
In no particular order. Which of these fits depends on your situation, not on the question you typed.
Automate it
All four conditions hold and the stakes are ordinary.
Document and simplify first
The steps repeat but live in people's heads.
Build it with help
The information is sensitive or a mistake is expensive, so design and approvals come first.
Leave it
It is rare, or changes too often for anything built to keep up.
When doing nothing is the right call
If the process is about to change, waiting until it settles is the cheaper decision. Automating a process mid-redesign produces something that needs rebuilding as soon as it works.
What the diagnostic asks
- Whether the work is mostly repeatable or different every time.
- How much judgement it needs.
- How often it comes round.
- What a mistake costs, how sensitive the information is, and whether software already exists.
“I don't know” is always an answer. Nothing is assumed on your behalf.
The routes it weighs
Every diagnostic weighs all ten routes. These are the ones that tend to matter for this question — a description of the rules, not a promise about your answer.
Process improvement
Change how the work flows — remove steps, name an owner, fix the hand-offs.
AI Assist
Keep a person in charge and give them AI for drafting, summarising, checking or analysis.
AI Agent
Delegate a defined, repeatable workflow to software inside boundaries you set, with human oversight.
Do nothing yet
Record the issue, set a revisit date, and decide what would change your mind.
Specialist support
Bring in a freelancer, consultant or specialist for a defined piece of work.
What changes the answer
- An undocumented process is not ready, whatever else is true.
- Rare work rarely pays back the setup, however repetitive it is.
- High stakes or sensitive information change who should build it, not whether it can be built.
Get your own read
A handful of short questions, then the strongest route for your situation, what's also credible, what we still don't know and what would change our view. No account, no setup.
Related questions
- Should I document the process before automating it?Yes, and not because documentation is virtuous. Writing it down is how you find the steps that should not exist — which is most of the value automation ever delivers.
- What should I automate first?The most frequent, most repeatable, best-understood, lowest-stakes thing you do. Not the most annoying one, and not the one with the best demo.
- Should I automate this work?If it is repeatable, frequent, low-judgement and written down, quite possibly. If any of those is missing, fix that first.
- When is an AI agent the wrong answer?When the process is undocumented, the work is rare, the judgement is high, the stakes are serious without a design to match, or a system you already pay for does most of it.
- Can AI help my team?Often, but the useful question is where. AI that helps a person draft, summarise or analyse is a different decision from AI that runs a process.
- Should I automate reporting?Usually yes, and usually after asking which reports anyone actually uses. Automating a report nobody reads makes it permanent.