Most failed automation projects look great in the demo. Someone shows you the agent handling a clean example end to end, the room nods, the budget gets approved. Then it goes into the real operation and starts producing work that is confidently wrong in ways nobody anticipated, and within a quarter there is a person quietly cleaning up after it full time.
The reflex is to blame the tool. Sometimes the tool really is the problem. More often the company tried to automate a process it had never actually written down, run by people whose real value was in the parts of the job that were never visible on the org chart. The agent learned the happy path. It never learned the exceptions, because nobody had ever made the exceptions explicit. They lived in someone's head.
This is the part of AI adoption that does not make it into the keynote. The hard work is not in buying the agent or training it. It is in understanding the workflow well enough to know which parts can be handed to a machine and which parts are holding the whole thing together.
A useful way to think about it: you have to earn the right to automate a workflow before you automate it. Earning it means running the process with skilled people first, watching where their judgment actually gets used, and documenting it, until you can describe the work precisely enough that you could hand it to someone who has never done it. Only then do you know what you are really asking the agent to do. Plenty of the generative AI pilots that stall out do so not because the model was weak but because the organization could not specify the work clearly enough for any system, human or machine, to execute it reliably.
Here is a composite, drawn from conversations across the last year with operations leaders in a few different industries. The details are blended to protect everyone involved, but the shape will be familiar.
A growth-stage company has a back-office workflow that has gotten expensive: a coordinator receives requests from customers, checks them against a handful of systems, resolves the discrepancies, and pushes the clean version downstream. Volume is climbing. Leadership sees an obvious automation candidate, buys a capable tool, and points it at the workflow.
It works for the requests that arrive complete and correct. The problem is that a meaningful share of them do not. A field is missing. Two systems disagree. The customer wrote something in the notes that changes how the request should be handled. The experienced coordinator had been resolving these quietly for years, making a dozen small judgment calls a day that never appeared in any procedure document. The agent had no idea those calls existed, so it either guessed or pushed bad data downstream, and the errors surfaced weeks later in places that were hard to trace back.
The fix was not a better model. It was going back and doing the work that should have come first. The team sat with the coordinator and mapped what actually happened on the messy requests, the tacit knowledge that had never been captured. They wrote down the exception logic. They defined what "good" looked like and what should trigger a human review. Once the workflow was understood at that level of detail, the automation had something real to work against, and a named person owned the calls the agent was not allowed to make on its own. The second version held up, because this time the company knew what it was automating.
The instinct to automate first and figure out the details later comes from treating a workflow as a cost to be removed. Looked at that way, the experienced people in it are an expense, and the faster you replace them the better.
The trouble is that the cost and the knowledge are the same asset. The reason that coordinator was expensive is the same reason the process ran smoothly: years of accumulated pattern recognition about what goes wrong and how to fix it. Remove the person before you have extracted the knowledge and you do not just lose capacity, you lose the map of how the work actually gets done. Now you are automating blind.
Process documentation has a reputation for being tedious, and it is, which is exactly why so many companies skip it and pay for it later. There is a reason mature operations treat process governance as a standing discipline rather than a one-time project. A documented, well-understood process is the precondition for trustworthy automation. An agent built on top of a vague process inherits the vagueness and adds speed to it.
When the sequence is right, the work splits cleanly. The routine, high-volume, well-specified portion goes to the agent. The exceptions, the judgment calls, and the moments where a wrong answer is costly stay with a person who has the context to handle them. The agent does more of the volume over time as the edge cases get understood and encoded, and the human owner stays in the loop on everything that requires a real decision.
This is also where a well-run managed operation has an advantage that is easy to miss. A team that runs the same class of workflow across many clients has already done the expensive part: it has seen the exceptions, written down the judgment, and figured out where automation belongs and where it does not. Bringing in that kind of team gives you more than capacity. You are importing a workflow design that has already been earned somewhere else, with the automation set where it has proven it can carry the load and a person owning the rest. The work still gets done by people who have seen the problem before, and the agent handles the volume it has earned the right to handle.
If you are evaluating a workflow for automation right now, resist the pull to start with the tool. Start with the work. Can you describe the process precisely enough that a capable newcomer could run it from your documentation, including the messy cases? If not, that gap is the project, and no model will close it for you.
Map where the judgment lives before you remove the people who supply it. Document the exceptions, not just the happy path. Put a human owner on the calls that are expensive to get wrong. Then automate the part you understand cold, and widen the agent's territory as you come to understand more. It is slower at the front end than buying a tool and flipping it on, and it is the version that is still running a year later instead of being quietly walked back.
___________________________________________________________________________________________________
|
|
About the Author: Jen Spencer is the Chief Growth Officer at Booth. She spent nearly a decade scaling a 300-person agency on the GTM side before stepping in as CEO and now advises and invests in early-stage SaaS companies. She's the author of Lead Anyway, a permission-slip book for leaders ready to stop performing and start leading on their own terms.
|