Cleanly documented workflows have one blind spot. They describe how the workflow runs when nothing gets in the way. For onboarding a new colleague, that is enough. For AI automation it is not, and the reason has nothing to do with the tool.
In a reference project with a design studio, the work on company context revealed a dependency on a single person that a significant share of revenue was hanging on. Nobody had held anything back. It simply was not written down anywhere. We see the same pattern whenever we look at a workflow in detail: the documented part is correct and complete. What is missing are the decisions somebody makes in passing.
When AI automation in an SME does not deliver, in our experience the tool is rarely the reason. These decisions usually are.
Why every description covers only the normal case
Ask someone who has handled order entry for years to write down the workflow. You get a clean description: mail arrives, data into the system, confirmation out, filed. All of it correct.
What it does not cover is what happens when the order carries no article number, or when the same customer asks for yet another partial delivery that the framework agreement does not provide for. In both cases the person decides correctly and never records it.
This is not a question of discipline. Someone who has run a workflow for a long time does not experience these cases as exceptions, they experience them as the workflow. There is nothing to hold back, because in that person's head there are no two categories. The description ends up incomplete without anyone noticing.
For a human being this is harmless. A new colleague asks about the first odd order, because she is unsure. A system is not unsure. It may well flag an unusual case, but it does not know which deviation costs money in your company and which does not. In doubt it produces a plausible result instead of a question. The difference from an experienced person sits less in speed than at this one point: she stops when something strikes her as odd.
This is why a value project with us does not start with the tool. Anyone who wants to automate a first process needs two things beforehand: what the workflow costs today, and where it departs from the normal case.
The pattern is older than AI
Lisanne Bainbridge described this in 1983 in the journal Automatica, long before any language AI. Her finding: automation takes away the easy parts of a task and thereby makes the difficult parts more difficult (Ironies of Automation, Automatica 19/6). Her subject was the monitoring of automated plants. The mechanism has stayed the same.
Translated into plain terms: the routine disappears from a desk, the rare cases stay behind. Someone who used to enter many orders a day, most of them without looking closely, is assigned only the ones where something is off. Those take more judgement than all the rest together. The practice that came with the normal case, which used to run along in the background, falls away at the same time.
This is not an argument against automation. It is the reason the deviations belong in the planning and not in the aftermath. Whoever discovers them only in live operation has two building sites at once: a system waving the wrong cases through, and people catching the remainder without preparation.
The same mechanism explains why the calculation beforehand often turns out too optimistic. When you work out what a workflow costs today, the item errors and rework belongs, in our experience, largely to exception handling. It rarely appears in any time tracking, and it does not disappear because the normal case now runs automatically.
What AI automation really hangs on in daily operation
One sentence reliably indicates, in our experience, that the deviations still sit in one person's head: "That is mostly right, I will take another look."
That second look is the exception handling. It has no name, no time in the calendar and no deputy. As long as a human checks every result, it holds, because this person knows what she is looking for. That knowledge, too, is written down nowhere.
An example that shows it well: checking and coding incoming invoices. The normal case is quickly described, the invoice matches the order, the cost centre is on the order. It can deviate in several places. The amount is a few francs above the order because a surcharge was added. The invoice carries no order number because somebody ordered by phone. The same line item belongs to a different cost centre depending on the project. From the supplier name an experienced person recognises which case this is, and steps in. AI automation codes the invoice in all of these cases, cleanly, traceably and wrongly. It will not show up at the time of booking, but weeks later in the project accounts.
The uncomfortable test: ask the person who checks what she pays attention to while checking. If a list comes back, the deviations are recorded, even if they exist only verbally. If the answer is "I see it when I see it", this workflow does not yet run without this person. That says nothing about the person and everything about the maturity of the workflow.
The same gap shows up with agents on a larger scale. Of the five work packages we described in the work behind an agent rollout, one is called process knowledge: workflows captured so that an agent can work with them. Without that work, an agent is a temporary hire on day one, with access to everything and no sense of what is unusual.
What makes the deviations visible
The question "what exceptions do you have here?" leads nowhere. It asks somebody to form a category they do not have.
Ask about the last concrete run instead of about the workflow in general. "What was different last Thursday compared with the Thursday before?" is a question people can answer, because they remember the case and not a rule. The answer usually arrives as a story, and inside that story sit the decisions that appear in no document.
Count instead of asking. Across a handful of runs, somebody notes every time they depart from the description, in one sentence and without judgement. After two weeks there is a list on the table that no interview would have produced. In our experience it is longer than expected and shorter than feared.
The most useful line in a work instruction is, in our experience, the one that says when it does not apply. An experienced person derives that on her own. A system needs the sentence spelled out, otherwise it applies the instruction to the case it was never meant for as well. In our view that line decides the outcome more often than the choice of model.
This is deliberately not a form. An empty template does not solve the problem, it moves it into a table that nobody fills in.
The workflows where this does not apply
There is recurring work where the normal case is the whole case. The report that pulls the same fields from the same system every month. The reminder that goes out after seven days without an answer. There is barely anything to gather there, and such workflows are the most comfortable entry into AI automation, because they run quickly and break nothing.
The difference comes down to a question you can answer without preparation: does somebody make a decision in this workflow, or do they only execute? Where nobody decides, the description is complete. Where somebody decides, the interesting part is missing from the description, however cleanly it is written.
The workflows with decisions are usually the more expensive ones. That is why the effort pays off there, and why the calculation also tips fastest there when the deviations only surface in live operation. AI automation that starts at the executing end gets going faster. One that starts at a decision delivers more and needs the preparatory work.
What you do not need a project for
You do not need software that reconstructs workflows from log files. For a workflow that runs weekly and that three people in the house know, that is too much apparatus for too little insight.
You do not need a documentation project either. Forty pages of described workflow are not automation, they are forty pages. And you do not need a second AI platform as long as the deviations of the first workflow are not on a single sheet.
What it costs is a few conversations and some attention across a handful of runs. That observation is hard to make up for later, though, once building has started and the workflow looks different than before.
If you cannot judge whether a workflow at your company is ready, bring it to a free initial conversation. We will tell you what we see, even if the answer is that this workflow is not the one to start with. How we work with AI in daily operations is there to read beforehand.
The question for the person who does it today
Take the workflow that annoys you most. Go to the person who runs it, and ask not about the process but about the last run. What came in, what was unusual about it, what did she do differently as a result. Write down every deviation, including the one she says is not worth mentioning. That one above all.
After three conversations like that you know whether you have a workflow or a person carrying a workflow. Both are fine. Only one of them can be automated.
Which deviation in your workflows does nobody record, because at your company it has long counted as normal?
Frequently asked questions
Why does AI automation fail on the exceptions?
Because the description of a workflow captures the normal case. An experienced person catches the deviations in passing without recording them. A system may flag unusual cases, but it does not know which deviation costs money in your operation, and in doubt it produces a plausible result instead of a question.
Is a documented work instruction enough for automation?
It is enough to onboard a person, but usually not enough for automation. What is missing is the line saying when the instruction does not apply. An experienced person derives that on her own, a system needs it spelled out, otherwise it applies the instruction to the wrong case as well.
How do I find the exceptions in a workflow?
Ask about the last concrete run instead of the workflow in general, because people remember cases rather than rules. In addition, have someone note across a handful of runs whenever they depart from the description. No interview produces that list.
