There is a conversation happening in almost every operations team right now about where AI can take over the work. The technology is genuinely capable, the appetite is real, and the question sounds simple: which of our processes can we hand to AI. Then the project starts, and it runs into something that has nothing to do with the technology. When someone sits down to specify exactly how a process works, so that it can be automated, they discover that no one can quite say. The process lives in the heads of the people who do it, as habit and judgement and a thick layer of exceptions, and it was never really written down. The blocker is not the AI. It is that you cannot automate what you cannot describe, and most operations cannot describe themselves.
This is the quiet reason so many AI automation efforts stall. They are aimed at real work that genuinely could be helped, but they assume the work exists as a clear, specifiable process, and it usually does not. The moment you try to hand a process to a machine, you are forced to state it precisely, and that act of stating it exposes just how much of your operation runs on knowledge that has never left anyone's head.
Automation needs a specification, and your operation does not have one
A machine, however clever, can only follow a process that can be described to it. That description does not have to be code, but it does have to be explicit: these are the steps, this is the data each one uses, these are the rules for the decisions, this is what happens in the awkward cases. The trouble is that most operational processes have no such description. The official version, if one exists, is a tidy diagram that bears only a passing resemblance to the real work. The real work is what the experienced people actually do, and much of that is tacit, learned by doing the job for a year next to someone who already knew it. Ask them to explain it fully and they will give you the main path and forget the dozens of exceptions they handle automatically, because to them those exceptions are not decisions any more, they are reflex. That reflex is exactly what a machine does not have.
The exceptions are the whole problem
When people imagine automating a process, they picture the main path, and the main path is usually easy. What makes real work hard to automate is everything hanging off that path: this customer is handled differently, that product skips a step, this figure gets checked by hand because of something that went wrong years ago, that case needs a judgement call no one can quite articulate. These exceptions are the accumulated intelligence of the operation, and they are precisely the part that lives only in people. An automation built on the clean main path will work beautifully in a demo and then fail the moment it meets the reality the exceptions exist to handle. You cannot automate around exceptions you have never written down, and you cannot write them down without first going and watching the work.
The describing is the work
Here is the reframing that changes how these projects should be run. The hard, valuable part of automating a process is not the automation. It is the describing. It is going to where the work actually happens, watching how it is really done, and capturing the true process, exceptions and judgement included, honestly enough that you could hand it to someone, or something, that had never done it before. That is difficult, unglamorous work, and it is most of the job. It is also where most of the value turns out to live, because a process you have finally described clearly is one you can improve, simplify, delegate, and only then, where it makes sense, automate. Teams that skip the describing and jump straight to the tool are trying to automate a thing they cannot see, and the tool cannot see it either.
What you find when you finally look
Two things almost always emerge when an operation forces itself to describe a process before automating it. The first is that the process is far more complicated than anyone believed, weighed down by years of exceptions and workarounds understood by only a handful of people, which is the very reason it resisted automation for so long. The second, and the more useful, is that a large share of the benefit people were hoping AI would deliver comes simply from having made the work explicit. Once you can see the whole process, the obvious moves appear: retire the steps whose reason has gone, standardise the parts that vary for no good reason, fix the broken joins between systems. Very often the biggest gains come from that cleanup, and only a smaller, carefully chosen slice of the work genuinely needs AI. The describing does not just enable automation. It frequently delivers most of the win before any automation is added.
A worked example
A team came to us wanting to use AI to automate a document-heavy approval process that was slow and dependent on two long-serving staff. They assumed the answer was a model that could read the documents and make the calls. Before building anything, we asked them to walk us through the process exactly as it happened, and the walk-through was revealing. The official process had five steps. The real one had those five plus a web of exceptions: certain clients routed differently, certain amounts triggered an extra check, certain documents were quietly fixed by hand before they ever entered the system. None of this was written anywhere; it was carried by the two experienced people, which was why only they could run it. We spent the first stretch of the work simply describing that reality in full. In doing so we found that a good part of the slowness came from obsolete checks and manual rework that could be removed or connected outright, with no AI at all. Once the process was clean and explicit, the genuinely judgement-heavy part that remained was a small, well-defined slice, and that slice was where we applied automation. The result was faster and far less dependent on two people, and most of the improvement came from the describing, not the model.
Describe first, automate second
The instinct to reach for AI is understandable, because the technology really can do remarkable things. But pointing it at a process nobody can describe does not produce automation; it produces fast, confident unreliability, because the tool inherits every ambiguity in work it was never able to see clearly. The organisations getting real value from AI in their operations are not the ones with the best models. They are the ones that did the patient work of understanding how their operation actually runs, exceptions and all, and then applied automation to the parts that were ready for it. Describe the work first. You will get a clearer, better operation out of the describing alone, and you will know exactly where AI belongs, which is a far better position than automating a process you were never able to explain.
Making an operation explicit enough to improve, and then applying automation only where it genuinely earns its place, is exactly what our AI and intelligent workflows work is built around: understanding the real process first, cleaning up what does not need a machine, and automating the part that does. Book a discovery call and we will help you see the work clearly before you try to automate it.
Frequently asked questions
Why do AI automation projects fail in operations?
More often than not they fail not because the technology cannot do the work, but because the process being automated was never actually described. Most operational processes live in the heads of experienced people, carried as habit, judgement, and a large collection of exceptions that nobody has written down. AI can only automate a process that can be specified, so when a team points an automation at work that exists only as tacit knowledge, there is nothing coherent for it to learn or follow. The project stalls not on model quality but on the discovery that the organisation cannot say, precisely, how the work is really done.
What has to happen before you can automate a process with AI?
You have to make the process explicit. That means watching how the work is actually done rather than how it is supposed to be done, capturing the real steps, the decision rules, the data used, and above all the exceptions and the judgement calls that experienced people apply without thinking. Only once the process is described honestly, exceptions and all, can you decide which parts are suitable for automation, which need a human, and which should be simplified or fixed before any technology touches them. The describing is not preparation for the real work; it is most of the real work, and it delivers value even if no AI is ever added.
Does AI remove the need to document and standardise processes?
No, it makes that need more acute, not less. There is a hope that AI is clever enough to absorb a messy, undocumented process and simply figure it out, but in practice AI applied to an unclear process produces unclear, unreliable results at speed, and inherits every ambiguity and bad assumption in the work. Describing and, where sensible, standardising the process is what makes automation safe and useful. Far from being made obsolete by AI, clear process understanding is the precondition for using AI well, which is why the organisations getting real value from it are usually the ones that did the unglamorous work of understanding their operations first.
What do you often discover when you describe a process before automating it?
Two things, usually. First, that the process is far more complicated than anyone believed, carrying years of accumulated exceptions and workarounds that only a few experienced people fully understand, which is exactly why it resisted automation. Second, and more useful, that a large share of the benefit people hoped AI would deliver comes simply from making the work explicit: removing obsolete steps, standardising the parts that vary for no reason, and fixing the broken joins. Teams frequently find that once the process is properly described, the biggest wins come from cleaning it up, and only a smaller, well-chosen slice actually needs AI at all.