1. Automating a broken process
The most expensive mistake and the most common. Automation makes a process faster and more consistent; if the process is wrong, you now produce wrong results at scale and with more confidence.
Before automating anything, ask why each step exists. In nearly every process we map, at least one step exists because of a system that was replaced years ago. Automating it preserves a decision nobody would make today.
Cheap check: walk the process with the people who do it and ask “what would break if we stopped doing this step?” The answer is sometimes nothing.
2. Treating exceptions as an afterthought
The happy path is a fraction of the work. If exception handling is not designed and priced, the automation handles 80% of cases and dumps the rest on a person with no context and no queue.
Cheap check: write the exception list before signing anything. If it has fewer than five entries, it is not finished.
3. No way back
An automation that has processed two thousand records incorrectly needs an undo. Without idempotency and a reprocessing path, correcting an error means manual repair at scale.
Cheap check: ask how you would fix a day's worth of wrong output. If the answer involves a person editing records one by one, that is a design gap.
4. No monitoring
Automations fail silently. A scraper returns zero rows, an integration stops syncing, a rule stops matching. Weeks pass before anyone notices, and by then the damage is distributed through everything downstream.
- Alert on volume outside the expected range, not only on errors
- Alert on zero — the most under-detected failure of all
- Alert someone who will act, not a shared inbox
- Report weekly on what ran and what it produced
5. No owner
The person who commissioned it moves on. The supplier's engagement ends. The automation keeps running until the business changes around it, and then nobody knows whether it is still right.
Cheap check: name the owner before the build starts and put them in the documentation. If nobody will take it, that is a finding worth acting on before you spend the money.
6. No measurement
Without a baseline, you cannot prove the automation worked, cannot justify the next one, and cannot tell when it has stopped working. Six months later the value is a matter of opinion.
Cheap check: two weeks of measurement before anything changes. Minutes per unit, errors per hundred, elapsed time. It costs almost nothing and settles every future argument.
The pattern behind all six
Each mistake is a small piece of unglamorous work skipped under time pressure: mapping, exception design, reversibility, monitoring, ownership, measurement.
Together they are perhaps 20% of a project's effort and they determine whether the other 80% survives contact with a Tuesday morning.