AI automation has a poor completion rate, and the reason is consistent across the failures. The technology worked. The process underneath it was never understood.
This is a framework for avoiding that, written from the perspective that the interesting question is not what can be automated but what should be.
Automation amplifies, it does not fix
If a process produces inconsistent output because nobody agreed the rules, automating it produces inconsistent output faster and at greater volume.
This is why mapping comes first. Not a diagram for a deck — an honest description of what actually happens, including the exceptions, the informal workarounds and the person who quietly fixes things at the end.
That last one matters enormously. Undocumented human correction is present in most processes and is invisible until it is automated away.
The question 'who currently catches the mistakes?' identifies more automation risk than any technical assessment.
What makes a good candidate
Four attributes. A process missing two of them is usually not ready.
Good and bad automation candidates
Most failed projects picked from the right column because it was more visible.
Automate well
- High volume, repeated many times per week
- Rule-bound with few genuine exceptions
- Already documented or easily documentable
- Current cost measurable in hours or errors
- Output verifiable without expert judgement
Leave alone for now
- Low volume but highly visible and annoying
- Requires judgement or negotiation
- Undocumented and held in one person's head
- Changes shape every few months
- Failure reaches a customer with no checkpoint
Measure the baseline or skip the project
Before automating, record two numbers: hours currently spent, and error rate currently produced.
Without them, the outcome is unfalsifiable. Six months later somebody asks whether the automation paid for itself and the answer is a shrug with a positive tone.
These numbers are usually easy to obtain and consistently skipped, because gathering them is boring and delays the interesting part.
Where automation reliably pays in marketing and sales
The consistent winners, in rough order of return.
- Lead routing and alerting — high volume, rule-bound, and speed has direct revenue impact.
- Data enrichment at capture — repetitive, verifiable, and improves every downstream decision.
- Reporting assembly — genuinely tedious, entirely rule-bound, and frees senior time for interpretation.
- First-response handling outside working hours — with a clear handoff to a human, not a pretence of being one.
- Content production support — drafting from an outline you control, not deciding what to say.
- CRM hygiene — deduplication, field normalisation, stage enforcement.
The human checkpoint
Any automation whose output reaches a customer needs a defined point where a person can intervene. Not as a formality — as a real gate with an owner and a service level.
This reduces the theoretical efficiency gain, and it is the difference between automation that survives its first bad output and automation that gets switched off after one incident.
Design the checkpoint at the start. Retrofitting one after an incident is more expensive and considerably less pleasant.
Common mistakes
- Automating the most annoying task rather than the most constraining one.
- Skipping the baseline measurement, making return unprovable.
- Automating an undocumented process and discovering the exceptions in production.
- Removing the person who quietly corrected errors, without replacing the correction.
- Choosing impressive over reliable — brittle automation costs more than the manual process.
- Treating it as a finished project rather than a system requiring maintenance.