There's a moment in almost every automation conversation where someone describes a workflow and then says, "we just want that to happen automatically." It's a reasonable wish. It's also, more often than not, premature — because when you ask a few follow-up questions, it turns out nobody fully agrees on what "that" is. The intake step depends on who's in the office. The approval sometimes goes through one manager, sometimes two. The final handoff works because one person has learned to chase it.
Automating that workflow doesn't remove the ambiguity. It hardens it. The software will faithfully execute whichever version of the process you happened to describe on the day you built it, and it will do so at speed, without judgment, and without the quiet human corrections that were holding the old version together.
Automation doesn't fix a process. It multiplies whatever the process already is.
Why broken processes get worse, not better
Manual processes have a hidden asset: the people running them. People notice when something looks off. They catch the duplicate entry, reroute the misdirected request, quietly redo the step that came through wrong. None of this appears in any process document, but it's real work — and it's the reason a messy process can still produce acceptable results.
Automation removes those human checkpoints. That's the point — and it's also the risk. If the underlying process has unclear ownership, inconsistent inputs, or exception paths that live in someone's head, automating it means the errors flow through faster and surface later, usually in front of a customer. And because the work now happens invisibly, the people who used to catch problems no longer see them go by. You haven't reduced the breakage. You've laundered it.
A short diagnostic before you automate anything
None of this means automation is a bad idea — it means readiness is a real question. Before automating a workflow, work through these questions in order. A weak answer to any of them is the actual project.
- 1. Can two people describe this process the same way? If the descriptions diverge, you don't have a process yet — you have habits.
- 2. Who owns the outcome? Not the steps — the result. If the answer is "sort of everyone," the automation will have no one to answer to either.
- 3. What are the exceptions, and how are they handled? If exceptions are handled by improvisation, list them explicitly. Automation needs the exception paths defined, not discovered.
- 4. Are the inputs consistent? Automation built on messy intake — free-text requests, incomplete forms, data living in three places — spends its life mishandling edge cases.
- 5. Which steps exist for a reason, and which exist out of habit? Automating an unnecessary step preserves it forever. This is your one cheap chance to delete it.
- 6. How will you know if it's working? Decide what you'll measure — turnaround time, error rate, time returned — before you build, not after.
The payoff for doing it in this order
Here's the encouraging part: the fixing is usually not a massive project. Clarifying ownership, standardizing intake, cutting steps that no longer earn their place — this is days-to-weeks work, not months. And it pays for itself twice. The process improves immediately, before any technology is involved. Then the automation you build on top of it is simpler, cheaper, and dramatically more reliable, because it's encoding something deliberate instead of something inherited.
Teams that skip the fixing step end up doing it anyway — mid-build, under pressure, with rework. Teams that do it first find the automation almost anticlimactic. That's what good looks like: by the time the software arrives, the hard thinking is already done.