There is a lot of enthusiasm about AI and comparatively little discipline about which workflows are worth automating. The projects that pay back share a small number of characteristics.
The four criteria
A workflow is a good automation candidate when it is:
- Frequent — happening daily or many times weekly. Automating a monthly task rarely justifies the build.
- Rules-based enough — the decision can be described, even if it involves judgement within known bounds.
- Tolerant of review — a human can check the output before it matters, or errors are cheap to correct.
- Currently expensive in time — someone is spending real hours on it now.
Workflows meeting all four are where the returns are. Workflows meeting two are where projects quietly die after six months.
What works well
Lead qualification. Enquiries arrive, get parsed, matched against criteria, scored and routed. Ambiguous cases escalate. Frequent, rules-based, easy to review.
Meeting notes and follow-up. Transcription, summary, action extraction, CRM logging and a drafted follow-up email for a human to send. Saves hours weekly with almost no downside risk.
First-line support triage. Categorise, route, answer the genuinely common questions, escalate everything else. The key is a conservative confidence threshold.
Report drafting. Pull the numbers, identify what changed, draft the commentary. The analyst edits rather than writes from scratch.
What tends to disappoint
Fully autonomous customer communication. The failure mode is a confidently wrong answer sent to a customer with nobody in the loop. The occasional bad outcome costs more than the time saved.
Automating a broken process. If the underlying workflow is a mess, automation produces a faster mess. Fix the process first.
Anything requiring perfect accuracy with no review step. Language models are probabilistic. Designing as though they aren't is how automations cause damage.
Design the failure case first
Every workflow we build starts from what happens when it's wrong:
- What confidence threshold routes to a human?
- What does the human see to make the call quickly?
- What gets logged so we can audit the decision later?
- What alerts if failure rates rise?
If you can't describe the failure case, the automation isn't ready to build.
Start with one
The pattern that works is picking a single workflow, measuring the hours it currently consumes, building it properly with review steps, and measuring the hours after. A demonstrated result on one workflow makes the next five straightforward to justify.
Attempting to automate everything at once produces a lot of half-finished automations that nobody trusts.