Process documentation for automation: the detail that actually matters

Most automation projects that stall, stall in the same place: nobody can explain precisely how the process they want to automate actually works. Process documentation sounds like paperwork —and it is, when it's written for the filing cabinet— but when the reader of the document is a robot, a workflow or an AI agent, it stops being paperwork and becomes the technical specification of the project. If it's wrong, what gets built is wrong.

The bad news is that the documentation most companies already have is useless for this. The quality manual, the diagram someone drew in 2021, the ISO procedure: they all describe the process that should happen, not the one that does. The good news is that documenting a process at the right level of detail takes days, not months, as long as you know what to write down and what to ignore.

This guide covers what information whoever builds the automation really needs, who should write it, how to handle the section everyone leaves for last —the exceptions— and how to tell whether what you have is already enough to request comparable quotes.

What does it mean to document a process so it can be automated?

Documenting for automation isn't narrating what the team does. It's answering, step by step, four questions a machine needs resolved before it executes anything:

• What triggers the step? An incoming email, a new record in the ERP, a time of day, a person's decision. If the trigger is "when Martha notices it", write that down too, because it's a human trigger and someone has to decide whether it stays.
• Where does the information come from? System, screen, field, file, folder. "From the ERP" doesn't cut it. "From the `expected_date` field in the order header in the sales module" does.
• What decision is made, and under what rule? This is the core. Most steps hide a criterion nobody has ever written down: "if the amount is high I escalate it to management". How high is high? Always? What if it's a long-standing customer?
• Where does the result land? What gets created, what gets modified, who gets notified, and how you know the step finished correctly.

A process documented this way can be read top to bottom and turned into a workflow without asking again. A process documented as prose ("the department reviews the paperwork and, if everything is correct, proceeds with processing") cannot be automated: reviews what, correct according to whom, processes how.

Practical rule: if the person reading the document has to ask you something before they can execute it, that something is missing from the document.

Why doesn't the quality manual work?

Because it was written for a different reader. A quality procedure exists to prove to an auditor that controls are in place; it's written in terms of responsibilities and evidence, not data and conditions. Three differences make it unusable as a specification:

| Quality manual | Documentation for automation | |---|---| | Describes the approved, idealised process | Describes the real process, shortcuts and rework included | | Talks about departments ("Admin validates") | Talks about systems, fields and concrete rules | | Leaves out exceptions as "one-off cases" | Exceptions are half the document | | Updated once a year, if that | Updated every time a rule changes |

There's a second, less technical and more uncomfortable reason: the approved process and the real one drift apart over time because the team invents shortcuts to get the work out. Those shortcuts usually aren't indiscipline, they're the smart answer to a system that doesn't help. Automate the manual and you automate the version the team already abandoned — on day one in production, twenty cases will show up that "have always been done differently".

When the process leaves traces in the systems (orders, case files, tickets), process mining lets you reconstruct that real flow from the event logs, without depending on what each person remembers. When it doesn't —because it lives in emails and spreadsheets— there's no substitute for sitting down and watching.

Who should write the process documentation?

Short answer: whoever executes the process, accompanied by someone who knows what to ask. Not one without the other.

• The person who executes it knows the exceptions, the shortcuts and the odd cases. But they take for granted what they've been doing for eight years, and they skip exactly the steps a machine can't guess.
• The analyst (internal consultant, systems lead, vendor) knows what to ask and in what format the answer is needed, but has no idea what happens when a supplier sends a delivery note with the wrong order number.
• The process owner doesn't write, they decide. Their job is to resolve the ambiguities that surface: when the document says "it depends", someone has to fix what it depends on.

The format that works best is a two-hour session with the person who executes the process, recorded or with someone taking notes, walking through the process with a real case open on screen. Not an interview in a meeting room: the process in front of you, clicking through it. The single most productive sentence in the whole session is "and what happens if...?".

Then the draft goes back to the executor for corrections. There are always corrections, and they're usually the important ones.

What level of detail is useful, and where does it become waste?

The usual mistake is going to one of two extremes: half a page that specifies nothing, or forty pages nobody will ever maintain. The useful level has a simple test: go into maximum detail on what the machine will execute, and summarise what a person will keep doing.

In practice, for a mid-sized process (say, from receiving a supplier invoice to posting it), a useful document runs 4 to 8 pages and contains:

| Block | What it includes | Why it matters | |---|---|---| | Scope | Where the process starts and ends, and what's out | Stops the project growing at the edges | | Volume | Cases per month, peaks, seasonality | Decides whether automating pays and what architecture holds | | Main flow | Steps of the normal case, with trigger, data, rule and result | This is 70-80% of cases | | Decision rules | Every condition written as a checkable rule | Saves the most time during development | | Exceptions | Which cases fall outside and what happens to each | This is where pilots die | | Systems and access | Which applications are involved, with which user and permissions | Determines the integration cost | | Definition of "done" | How you know a case finished correctly | Without it there's nothing to measure or test against |

What's almost always waste: the history of the process, the org chart, decorative screenshots and descriptions of steps the project won't touch. If a section doesn't change a single design decision, cut it.

What do you do with the exceptions?

This is where the real work is. A typical process has a main path covering 70-80% of cases and a long tail of situations the team handles manually without thinking of them as exceptions, because they come up every week.

The way to surface them is to ask about the concrete case, not the process in the abstract:

• What was the last case that gave you trouble? What was odd about it?
• What do you do when a piece of data is missing? Wait, make it up, call someone?
• What happens if the same thing arrives twice?
• Which case forces you out of the system and into email or a phone call?
• Is there a customer or supplier treated differently "because it's them"?

Each exception goes into one of three buckets, and the process owner does the sorting, not whoever is writing:

1. Automate it anyway. The exception has a clear rule, it just had never been written down. It goes into the flow. 2. Route it to a person. The machine detects the case, flags it and drops it in a queue with the full context. That isn't a project failure: it's the right design for judgement calls. 3. Kill it. Many exceptions exist because someone asked for something years ago and nobody has revisited it. Automation is an excellent excuse to remove them.

The third bucket generates the most value and meets the most resistance. It's worth fighting for before a line of code is written: every exception you keep multiplies the cost of development and, above all, of maintenance.

How do you document a process in a week?

A plan that works for a mid-sized process, with part-time dedication:

| Day | What happens | Who | |---|---|---| | 1 | Set the scope and pull volumes from the systems | Process owner + systems | | 2 | Observation session with the executor, real case on screen | Executor + analyst | | 3 | Write up the main flow with trigger, data, rule and result | Analyst | | 4 | Exception session and sorting into the three buckets | Executor + owner | | 5 | Draft reviewed by the executor, ambiguities closed | Everyone |

With that in hand you can ask two or three vendors for quotes and compare like with like — impossible when each of them interprets a verbally described process their own way. And if you also want to estimate whether it's worth it, the document already holds what's needed: volume, manual steps and time per case. From there you work out whether the automation pays for itself, which we cover in more depth in the guide to AI process automation.

Recurring mistakes

• Documenting the process you wish you had. Document the current one first. Redesigning is fine, but it's a later, deliberate step, not something that creeps in while you write.
• Leaving rules as "it depends". If nobody sets the threshold, a developer will set it on their own and no one will find out until it goes wrong.
• Forgetting access. A beautiful workflow that needs a user with permissions that take six weeks to approve isn't a workflow, it's a wait.
• Never touching the document again. Documentation that isn't updated when a rule changes becomes a lie within three months. Name an owner and put it in the change process.
• Documenting for the machine and forgetting the people. The team doing the work today has to understand what changes in their day, or the new flow will be dodged exactly like the old manual was. That's change management, and it starts in this very phase.

Frequently asked questions

Do I need BPMN to document a process?

No. A structured document with numbered steps, explicit rules and exception tables is perfectly valid and everyone understands it. BPMN helps when the process has many parallel branches or when the organisation already uses it; if you have to teach the notation before you can start, it usually subtracts more than it adds.

How much of the team's time does documenting a process take?

For a mid-sized process, 6 to 10 hours from the person who executes it, split across two or three sessions, plus the analyst's writing time. Heavily branched processes or ones crossing several departments can need double that, and in that case it's better to split them into subprocesses with clear boundaries.

Can you automate without documenting, just by observing?

You can start by observing — in fact that's the recommended way — but the result of that observation has to be written down. What isn't written can't be reviewed, contracted, tested or maintained once the person who knew it moves on.

Who maintains the document once the process is automated?

The process owner, not the technical team. The documentation describes business decisions —thresholds, exceptions, criteria— and whoever changes them should reflect them. The technical team maintains the implementation; the process owner maintains the truth about how it should behave.

---

Documenting properly isn't a hoop the vendor makes you jump through to cover themselves: it's the part of the project where you decide whether what gets built is any use. If you're weighing up automating something and you don't know whether what you have documented is enough, in the audit we go through it with the processes on the table and tell you what's missing before anyone starts building. And if you'd rather talk it through, let's talk.