Every automation project I have been asked to rescue failed in the same place. Not at the technology — at the moment somebody had to say exactly what the process was, and discovered that nobody knew.
This is the normal condition of a working company. The process exists, it runs every day, and it lives in three people’s heads plus a spreadsheet one of them maintains privately. It has never been written down because it never had to be. Then someone proposes automating it, and the absence of a written process stops being a curiosity and becomes the whole problem.
What follows is the order I actually work in when a client wants to automate something nobody has documented. It is not a discovery phase in the consulting sense. It is four days of watching, and it is the cheapest part of the project.
Do not start by asking how it works
Ask a team to describe their own process and you will get the version they believe, which is the official version, which is not what happens. This is not dishonesty. Nobody can accurately narrate something they do by habit.
What you get instead is the happy path — the clean sequence with none of the exceptions, and the exceptions are where all the cost is. I have been given a five-step description of an approval process that turned out to have eleven steps and three ways of skipping them.
So do not ask. Watch, and count.
Day one: follow one item all the way through
Take a single real case — one invoice, one order, one application — and follow it from the moment it arrives to the moment it is finished. Sit with each person as they handle it. Do not intervene, do not suggest improvements, and above all do not ask why yet.
Write down four things at every step: what arrived, what the person did, what they had to look up somewhere else, and what they produced. That fourth column is the one that matters, because the output of one step is the input of the next, and automation is mostly about whether those two match.
Record the elapsed time too, not just the work. The gap between “this takes twenty minutes” and “this takes four days” is almost always queueing rather than effort, and GOV.UK’s guidance on measuring completion is a useful reminder that the number worth improving is the one the customer experiences, not the one your team feels.
One case takes half a day and tells you more than a week of meetings. The UK government’s discovery guidance makes the same argument in its own vocabulary: understand the problem and the users before deciding what to build, and expect discovery to change what you thought you were building.
Day two: find the exceptions
Now ask, and ask one question only: when does this not work like that?
You will get a list. A customer who pays in a different currency. An order that arrives by phone instead of the form. The client whose approval goes to a different manager because of something that happened in 2023. The month-end version, which is different.
Count them, and count how often each occurs. This is the single most valuable number in the project, because it decides the shape of everything after it. A process with two exceptions covering five per cent of cases is a good automation candidate. One with nine exceptions covering forty per cent is not a process — it is nine processes wearing one name, and automating it as if it were one is how these projects die.
Day three: separate the decisions from the steps
Go back through what you recorded and mark every point where a human decided something rather than executed something.
Executing is moving data, formatting, copying between systems, sending a notification. Deciding is judging whether a document is acceptable, whether an exception applies, whether a customer is a risk.
Notation helps here even if you never draw a diagram. BPMN distinguishes a task from a gateway for exactly this reason: a gateway is a point where the path forks on a condition, and every gateway in your process is either a rule you can write down or a judgement you cannot. Sorting them into those two piles is most of the analysis.
This line is the automation boundary, and getting it wrong in either direction is expensive. Automate the executing and you get most of the benefit at a fraction of the risk. Try to automate the deciding and you are building something that needs oversight, evaluation and a way to be wrong safely — a different project with a different budget, and the four questions in the decision nobody in the room was qualified to make apply before you start it.
Most processes are eighty per cent execution. That eighty per cent is where the money is, and it is boring, which is why it gets skipped in favour of the interesting part.
Day four: write it down and have it corrected
Now write the process out, in the order it happens, with the exceptions marked and the decision points named. Plain language, one page if possible. You do not need formal notation at this stage: a numbered list the team recognises beats a diagram they cannot read.
Then hand it to the people who do the work and ask them to correct it. They will. This step produces more corrections than the previous three days produced findings, because people cannot describe a process from memory but they can immediately spot when a description is wrong.
That corrected page is the actual deliverable. Everything after it is implementation, and implementation without it is guesswork with a budget attached.
What you will find, nearly every time
Three things recur often enough that I now expect them.
A step that exists because of a system that was replaced. Someone still exports to a spreadsheet because the old system needed it. The new one does not. Nobody removed the step because nobody owned it. Delete it before automating anything.
Two people doing the same check. Usually because a mistake happened once and a second check was added without removing the first. Decide which one is real.
The same pattern shows up in customer-facing work, where the fix is usually narrower than the ambition — the argument in where AI agents help in Kuwaiti customer service and where they fail.
A queue nobody is watching. Work arrives somewhere and sits until someone happens to look. This is where the delay your customers complain about actually lives, and it is often fixable with a notification rather than an automation.
All three are free wins available before any software is written, and they are the reason this exercise pays for itself even if the automation is cancelled. It is the same argument as reading a proposal properly: most of the value is in understanding what you are buying before you buy it.
Then, and only then, choose the tool
With a corrected process and an honest exception count, tool selection becomes a short conversation instead of a long one. That is also the point at which AI automation stops being a category and becomes a specific decision about specific steps.
What integrates with the systems you already have, what your team can maintain, and what happens when it fails.
And a caution about AI specifically, because it is what everyone now reaches for first. A language model is very good at the judgement-shaped steps and unnecessary for the execution-shaped ones. Using one to move data between two systems is expensive, slower and less reliable than the boring alternative. Anthropic’s own guidance on building effective agents makes the point plainly: start with the simplest thing that works and only add complexity when it demonstrably improves the outcome.
The corollary is uncomfortable and worth saying. A properly documented process often turns out not to need automating at all. Removing three redundant steps and adding one notification frequently delivers more than the software would have, at a fraction of the cost, and nobody gets to announce a project. That is a good outcome and it should be reported as one.
Why the documentation is the deliverable
Whatever happens to the automation, you now have something the company did not have: a written description of how work actually gets done, corrected by the people who do it.
That document is what makes the next person able to run the process, what makes the next system able to be scoped, and what stops the knowledge leaving when someone resigns. Martin Fowler’s framing of technical debt applies to process as much as to code: the undocumented process is a debt that is invisible until you try to change something, and then it charges interest all at once.
This is most of what the first month of a fractional CTO engagement looks like, and it is why I resist starting with tool selection. You cannot automate a process. You can only automate a description of one, and the description is the thing you are actually paying to produce.
Frequently asked questions
Four days sounds like a lot before anything is built.
It is four days against a project that is usually months. Every automation I have seen fail spent longer than four days discovering the same information halfway through the build, when changing course was expensive and someone had already committed to a date. The four days are not added to the project — they are moved to the front of it, where they cost least.
Our team says they are too busy to be watched.
Watching costs them almost nothing — you are observing work they are doing anyway, not holding a workshop. The expensive version is the one they are objecting to: a series of meetings where they are asked to describe the process from memory, which takes longer and produces a worse answer. Say that plainly and the objection usually goes away.
What if different people do the same process differently?
That is a finding, not an obstacle, and a common one. Document both versions and then decide which is correct — that decision belongs to the business, not to whoever is building the automation. What you must not do is quietly pick one and encode it. That is how automation ends up enforcing a rule nobody agreed to.
Can we skip this if we are buying off-the-shelf software?
No, and it matters more there. Off-the-shelf software encodes somebody else’s process, and the question is whether yours can bend to it. Without a written description of yours you cannot answer that during evaluation, so you find out during implementation, which is the most expensive moment available.
Who should do the watching?
Someone who does not do the work and is not going to build the system. A participant cannot see their own habits, and a builder unconsciously records the version that is convenient to build. If it has to be internal, pick someone from a different department and make it explicit that their job is to describe, not to improve.