What to Document Before You Automate a Process

Most firms that tell us their processes are documented are telling the truth. It usually does
not help.

The documentation exists. It is a folder of SOPs written by someone who already knew the job,
for colleagues who also already knew the job. It says things like "check the invoice against the
PO and process as usual." A new hire reads that, watches someone do it twice, asks four
questions over the first week, and is fine by the following Thursday. That is what the document
was for. It was never meant to carry the process on its own.

An agent gets no Thursday. It cannot watch someone do it twice, and it will not ask the four
questions unless you have told it which four are worth asking. Everything the SOP left out
because a person would obviously infer it is exactly the part that now has to be written down.

We have argued in several posts that a process nobody can describe cannot be handed to an agent
— when
deciding between automation and agents, when
scoping what an AI workforce can take on, and when
estimating how long a deployment takes. None of them
said how to fix it. This one does.

The test, before the checklist

Could someone do this from the document alone, on their first day, with nobody available to ask?

Not "would they do it well." Could they do it at all — and would you be able to tell afterwards
if they had got it wrong?

Try it on whichever process you were planning to automate first. Most people find their
documentation survives about two paragraphs before it needs a colleague. The six sections below
are what you add to get it the rest of the way.

Start with the trigger, and be suspicious if you cannot name one

What causes this work to begin? An email landing in a shared mailbox. A date computed from a
client's financial year end. A status field flipping in your CRM. A person noticing something.

If the honest answer is the last one, write that down as the answer rather than inventing a
tidier one. "Someone checks the folder when they get a moment" is a legitimate finding, and it
tells you the first thing an agent changes is not the work — it is that the work now starts
reliably.

Triggers you cannot name are usually triggers that fire inconsistently, which is often the real
cost of the process and not the part anyone was complaining about.

List where each input actually comes from, not where it is supposed to come from

This is the section that benefits from a table, because the interesting column is the last one.

Two of those three rows describe the process as designed. The third describes how it survives
contact with a Tuesday. Write down both, because an agent inherits the real version.

Be specific about which system holds each input and who owns access to it. "It's in the shared
drive" is not a location. Half the delay in a typical deployment is not model behaviour; it is
discovering in week three that one of the inputs lives in a spreadsheet on a laptop.

The decision points are the whole job

Everything above is inventory. This is the part that determines whether a process can be handed
over at all, and it is where almost every documentation exercise turns out to be thinner than
expected.

Take a rule that looks completely specified: approve the invoice if it matches the purchase
order. Now ask what your team actually does.

They approve it if the total is within a few dollars, because of currency rounding. They approve
a known supplier who always invoices in two parts against a single PO. They hold anything from a
supplier the finance lead flagged in March, which is written down nowhere. They escalate
anything where the GST treatment looks off, but only above a value that nobody has ever stated.
They approve a mismatch outright if the ops manager has already confirmed the delivery by
message.

That is five decisions inside one sentence, and four of them were invisible until someone asked.

For each decision point, you need three things: the rule as it is genuinely applied, the
threshold in numbers rather than adjectives, and who owns the outcome when it goes wrong. That
last one matters more than it looks. A decision without a named owner is one an agent will make
silently, which is fine until the first time it should not have.

Then separate the two kinds. Some of these are rules — conditions you could state to a new
employee and expect consistency. Others are judgement, where two experienced people would
reasonably disagree. Rules can be handed over. Judgement stays with a person, and the process
description should say so explicitly rather than leaving the boundary to be discovered in
production.

Go and count the exceptions. Do not estimate them.

Ask a team how often a process deviates from the standard path and you will hear "rarely."

Pull the last fifty cases and count. It is usually somewhere between a fifth and a third, and
the exceptions cluster into four or five recognisable types rather than being genuinely random.
Those types are the ones worth writing down. Whatever is left after that is the genuine
long tail, and the correct instruction for it is to escalate, not to guess.

This is an afternoon of work and it changes the scope of the deployment more than any other
single step.

Define "done" in a form something other than a human can check

"The invoice is processed" is not a definition. "The record exists in the accounting system with
a supplier, date, amount, tax treatment and PO reference, and the source document is filed
against it" is.

Write the state of the world when the work is finished — which records exist, which fields are
populated, which notification has gone out, what a person could look at to confirm it. If you
cannot describe the finished state as a set of facts, the process has no end condition, and
anything you hand it to will keep going.

The last question is the one everybody skips

How would you know if the output was wrong?

Most teams have never had to answer this, because the same person did the work and the checking
in one motion, and their eye caught the odd one. Once a process is handed over, that motion
splits in two, and the checking half has to exist on purpose.

So write it down: what does a correct output look like next to a subtly wrong one, who reviews,
how many, and how often. A process where wrong output is caught immediately by the next step can
be handed over aggressively. A process where a mistake surfaces two months later in a client
conversation cannot, and should be scoped with a human review gate from day one.

This is also the section that stops being theoretical the moment you deploy. What the agent
should log, how long you keep it, and who checks the checker are covered in our post on
managing an AI agent workforce — that is the
after-handover half, and it is a different document from this one.

The exercise stalls more often than it finishes. That is a result, not a failure.

Expect one of three outcomes, and only one of them is the one you set out to get.

Sometimes it works. You end up with a description precise enough to hand over, and the
deployment is straightforward because the hard thinking is already done.

Sometimes two people describe the same process differently and neither is wrong — they have both
been doing it their own way for years, and the variance was absorbed by everyone being
reasonable. You cannot automate an average of two processes. Someone has to decide which one is
the process, and that decision belongs to the business, not to whoever is building the agent.

And sometimes the exercise reveals that the process itself is the problem — that it exists to
patch a gap created somewhere upstream, or that three of its seven steps are copying data
between two systems that could talk to each other. We have made this argument before in the
context of choosing between automation and
agents, and it holds here with more force:
automating a bad process buys you the same bad outcome, faster and at greater volume.

Discovering this costs you an afternoon. Discovering it after a deployment costs considerably
more.

What you do not need to write down

The exercise expands to fill whatever time you give it, so it is worth being clear about what is
out of scope.

You do not need to document the clicks. Which button, which screen, which order — that is an
artefact of the current tool and it will not survive the change anyway.

You do not need to map the whole department. One process, end to end, is more useful than six
processes half-described. Picking the right one is a separate question, and one we have written
about in how to identify AI
opportunities.

You do not need perfect prose. A page of precise notes beats a polished document that hedges.
The failure mode here is not untidiness — it is the word "generally."

Where personal data enters, because the inputs list is where it surfaces

Under the PDPA, your organisation stays accountable for personal data even when a third party
processes it on your behalf. The inputs table above is where that obligation becomes concrete:
if any of those inputs contain personal data — customer records, employee details, client
financial information — note it in that row while you are already looking at it.

You want to know three things per input: what personal data it contains, how long you keep it
once the process is complete, and whether the arrangement with any external processor covers it.
Doing this during documentation costs nothing extra. Doing it after deployment means revisiting
every integration. Our post on PDPA compliance and AI
agents covers what the obligation looks like in
practice, including the part about breach notification that catches people out.

How to actually run it

Put the two or three people who do the work in a room for ninety minutes. Not the manager who
owns the process — the people who run it, including whoever covers when the main person is on
leave, because that person knows where the undocumented shortcuts are.

Walk one real case end to end, out loud, with someone writing. Do not start from the existing
SOP; start from an actual instance last week and let the exceptions come up naturally. When
someone says "usually" or "it depends," stop and ask on what. Those two words mark every decision
point worth capturing.

Then take the next fifty cases and check the description against them. The gap between what the
room said and what the fifty cases show is the part that would otherwise have surfaced in
production.

That is the whole method. It is not sophisticated, and it is the single highest-return afternoon
available to a firm considering agents — because the output is useful whether or not you ever
deploy one.

Frequently Asked Questions

How detailed does process documentation need to be before deploying an AI agent?

Detailed enough that someone could run the process from the document alone, on their first day, with nobody available to ask — and detailed enough that you could tell afterwards whether they got it wrong. In practice that means six things: what triggers the work, where every input genuinely comes from, each decision point with its real threshold and named owner, the exception types that actually occur, a definition of "done" stated as facts rather than a feeling, and how a wrong output would be caught. It does not mean documenting which buttons to click.

What if two people in my team describe the same process differently?

That is a common and useful finding. It usually means both versions have been running in parallel for years, with the difference absorbed by everyone being sensible. You cannot hand over an average of two processes, so someone has to decide which one is the process before anything is automated. That decision belongs to the business rather than to whoever is building the agent, and making it is often worth more than the automation that follows.

How long does documenting a process before automation take?

For a single workflow, about ninety minutes with the people who actually do the work, plus an afternoon checking the description against the last fifty real cases. The second half is the part teams skip and the part that changes scope most, because estimated exception rates are almost always lower than counted ones.

Do we need to document the process ourselves, or can a consultant do it?

Either, but the people who run the work have to be in the room — the undocumented thresholds and the exceptions only exist in their heads. A consultant is useful for asking the questions a team has stopped noticing it never answers, and for knowing which details a deployment will actually need. The documentation is not a deliverable you can outsource entirely, because the content of it only lives inside your operation.

ADV Digital Labs deploys and operates AI agents for Singapore SMEs. If the exercise above
stalls — or if you would rather not run it alone — a
free workflow audit is this exercise, run by people who have done it before and know
which gaps will matter once an agent is in production. You can also review
the four agent roles to see what the finished description gets handed to.

See also: Automation vs AI agents: how to
decide · Managing an AI agent
workforce · PDPA compliance and AI
agents