How to tell whether a workflow is ready for AI automation
A short checklist we run against every candidate process before quoting. Volume, ambiguity, and reversibility decide far more than how interesting the problem sounds.
6 min readWorkflow automation, AI agents, Process mapping
Most automation projects fail before any code is written. Not because the technology cannot do the work, but because the workflow was never a good candidate in the first place.
This is the checklist we run during a first call. It usually takes twenty minutes and it saves months.
1. Is the volume high enough to matter?
Count the occurrences per week, then multiply by the minutes each one takes. If the answer is under two hours a week, the honest recommendation is usually to leave it alone. Automation has a build cost and a maintenance cost, and there is no maintenance cost lower than a process that already works.
The number we look for is not a specific threshold. It is whether the person doing the work would describe it as a real part of their job or a small annoyance.
2. Is the input structured, semi-structured, or chaotic?
Structured input, such as a form field or a database row, is the cheapest thing to automate. There is no ambiguity to resolve and the work is mostly plumbing.
Semi-structured input, such as email or a standard PDF, is where modern tooling pays for itself. The document has a shape, but a person still has to read it.
Chaotic input, such as a phone call with no notes or a photograph of a handwritten form, is possible to handle but the error rate needs to be designed for from the start.
3. Are the rules already written down somewhere?
If two people can independently produce the same answer for the same input, the process has rules. Those rules may live in a spreadsheet, a policy document, or someone's head. The question is whether you can extract them.
If you cannot get two people to agree on the correct output, automation will not fix that. It will scale the disagreement.
4. What happens when the automation is wrong?
This is the question that decides how much freedom the system gets.
If the consequence is a wasted minute and an easy correction, you can ship aggressively and monitor loosely. If the consequence is a customer billed incorrectly, an appointment missed, or a compliance problem, the system needs a review step, a threshold, and an audit trail before it goes near production.
Reversibility, not accuracy, sets the pace of rollout.
5. Who owns the process today?
Automation without a process owner becomes an orphan. When the system produces a wrong answer, someone has to notice and say so.
We ask who will look at the exception queue and how often. If the answer is nobody, the project is not ready regardless of how clean the workflow looks.
6. Is there a measurable baseline?
You need a before number. Time to complete, error rate, backlog size, response time. Without one you cannot tell whether the system helped, and you cannot defend the invoice.
Establishing a baseline is usually the least glamorous week of a project and the one clients thank us for later.
The short version
| Signal | Ready | Not ready |
|---|---|---|
| Volume | Hours per week | Minutes per week |
| Input | Structured or semi-structured | No consistent format |
| Rules | Two people produce the same answer | Disagreement about correct output |
| Reversibility | Easy to correct | Customer-visible or regulated |
| Ownership | Named process owner | Nobody responsible |
| Baseline | Numbers exist | No measurement |
A workflow that passes all six is almost always worth automating. A workflow that fails three or more is usually a process problem that no model will solve.