Somewhere out there is a graveyard of automation projects. The workflow nobody uses. The integration that got switched off after the third bad sync. The bot that sent two hundred wrong emails on a Saturday. Different businesses, different tools, and the same few causes of death on every certificate.
We've been called in after enough of these to know the pattern, and the encouraging part is that every cause on the list is avoidable, cheaply, and usually before a penny is spent on software. Here's what actually kills automation projects.
"We should automate more" is an ambition, not a project. The failures start when the goal is the technology rather than a specific, measurable improvement to a specific workflow. If you can't say what will be better, by how much, for whom, you're not ready to build. You're ready to think, which is cheaper.
Automation is a photocopier for your process: it reproduces whatever you feed it, at speed. Feed it an inconsistent process where every case is handled slightly differently and you've automated the inconsistency. This is why mapping comes first, always, and why the projects that skip it fail with such reliability you could set your watch by them.
The demo handled the perfect case; the live system met real life. The duplicate, the missing field, the payment that half-happened. With no exception path, every oddity became a support ticket, trust drained away, and someone eventually said the fatal words: "just turn it off and we'll do it by hand." Exceptions aren't the edge of the design. They're the middle of it.
Three quiet assassins. Two systems both believed they owned the customer record, so the automation propagated disagreements at speed. The API key everything depended on belonged to a supplier who changed it, or a staff member who left. And after launch, no named person watched it, tuned it or answered for it, so the first silent failure ran for six weeks. Automation without an owner and an afterlife plan isn't a system. It's a countdown.
The staff who run a process daily know where the bodies are buried, and automation designed without them fails on contact with the first buried body. They're also the ones who decide, quietly, whether the new workflow gets used or worked around. Involve them from the first mapping session. It's respectful, and it's also the single cheapest insurance a project can buy.
The grand programme that automates the whole business in one go fails for the same reason every grand programme fails: too many assumptions tested too late. One workflow, proven, measured, then the next. Success measured by activity ("we deployed twelve automations!") counts nothing; success is the error rate, the turnaround time, the exceptions caught. Boring numbers, honestly earned.
That's the whole secret, really. Good automation is boring: mapped first, exception paths built, owners named, one step at a time. It's precisely how we run automation projects and AI integrations, and it's why our clients' automations are still switched on. If yours died one of the deaths above, it can usually be revived, properly this time.