There’s a failure mode nobody talks about enough: the process that’s 80% automated.
It sounds like progress. And it is — until you look at what that last 20% actually costs. Someone has to monitor the automated part, catch what it drops, manually fix the exceptions, and then reconcile everything at the end. That person needs to understand both the automation and the underlying work. They can’t fully trust the output, so they end up checking everything anyway.
Partial automation doesn’t split the work in half. It often creates more work than doing it manually from the start — plus it adds fragility, because now you have two systems that can fail instead of one.
Scott Andrew Alpaugh calls this the “almost-automated tax.” You pay it every time you ship a workflow that handles the easy cases and punts on the hard ones. The hard cases don’t disappear. They just arrive without context, stripped of the information that would make them solvable.
Good automation is designed around its failure states, not just its happy path. The question to ask before you build isn’t “what will this handle?” It’s “what happens when it doesn’t handle something, and who deals with that?”
If you can’t answer the second question cleanly, you’re not building automation. You’re building a liability that looks like a solution.
Finish the job or don’t start it. Half-measures compound.