Someone in the meeting always says it. A process is slow, so the answer is: automate it.
But automation doesn't fix a broken process. It just makes the broken process run faster, with less human judgment involved to catch the mistakes along the way. If the process was wrong before, automating it doesn't make it right — it makes it consistent, which is not the same thing.
The workflow that didn't need what it asked for
I've been called into projects where a company wanted to automate an approval workflow, convinced that speed was the problem. It wasn't. The real bottleneck was that three people didn't trust each other's numbers, so they were all independently checking the same spreadsheet before anyone would sign off on anything.
Automating the approval step wouldn't have touched that. It would have just made the wrong numbers move through the system faster, with fewer eyes on them before a decision got made. Speeding up a process built on mutual distrust doesn't fix the distrust. It just hides it better, for a while.
Three questions before you automate anything
Before I recommend automating any part of a business process, I ask:
What is this process actually trying to achieve? Not what it currently does, step by step, but the underlying outcome it exists to produce. Sometimes those have drifted apart over time.
Where does it currently break down? Not where it feels slow, but where errors actually enter, where people are waiting on something, where the same problem shows up repeatedly.
Is the breakdown a technology problem, or an information and trust problem? This is the question people skip. A lot of "slow" processes are slow because people don't trust the data, don't know who owns a decision, or don't have visibility into what's already been done. No amount of automation fixes that on its own.
Sometimes the fix isn't software at all
In the case above, the fix wasn't a faster approval workflow. It was giving one person clear ownership of the number everyone was independently re-checking, and making that number visible to the other two so they didn't need to verify it themselves every time. No software required. Just a clearer line of accountability.
Other times, the honest answer really is a script that removes twenty minutes of manual data entry a day, or an integration that stops three systems from disagreeing with each other. The point isn't that automation is bad. It's that automation applied to the wrong layer of the problem is expensive, because you pay for the build and you still have the underlying issue.
Paving a road to the wrong place
Technology should remove friction. It can only do that once you actually know where the friction is coming from. Automating a bad process is like paving a road that goes to the wrong destination — you get there faster, but you still shouldn't have gone.
If something in your business feels like it needs automating, the first useful step usually isn't writing code. It's mapping the process honestly enough to see whether the slowness is really a technology problem, or something else wearing a technology problem's clothes.