Workflow Documentation: Write Down the Exceptions, Not the Happy Path.
Most workflow documentation describes the day nothing went wrong. An order arrives, it is checked, it is picked, it ships, it is invoiced. The document is accurate and it is useless, for two reasons. The people who do the work already know the happy path and never read the document. And the thing the document was written for, an automation, a new hire, an AI agent, will meet the happy path on its first day and an exception on its second, and the document has nothing to say about the second day.
The exceptions are the document. This post is about why, how to capture them from the people who carry them in their heads, and a two-page format that has worked for us across enough mid-market operators to trust.
Why the happy path is not worth writing down.
The happy path is the process the system already runs. In a Zoho estate, in an ERP, in a spreadsheet, the standard case is what the tool was configured for and what the person does without thinking. Documenting it produces a manual for the tool, which the vendor already wrote.
What the tool was not configured for, and what the person does by judgment, is everything else: the rush order, the customer with two billing addresses, the partial shipment, the credit hold that was lifted by phone, the return without a receipt, the invoice that has to be split across two purchase orders. Each one is handled, today, by someone who knows how. None of it is written down, because the person who knows how does not think of it as a process. They think of it as their job.
That knowledge is the most valuable operational asset the company has and the least protected. It leaves when the person leaves, it cannot be automated because it is not written, and it is exactly what an AI initiative needs and cannot find. We have argued that process documentation is the precondition for automation; this post is about which half of the process to document.
What an exception actually is.
An exception is a point in the workflow where a person makes a decision the system does not make for them. That is the whole definition, and it is worth keeping tight, because it turns documentation from a writing task into a listing task.
For any workflow, the exceptions are found by asking one question at each step: what happens here when the normal case does not apply, and who decides? The answers are short. "If the customer is on credit hold, the order waits; the controller decides whether to release it; she looks at the ageing and whether the customer paid last month." Three sentences, and they contain everything an automation or a new hire needs: the condition, the decision-maker, and the information the decision uses.
How to capture them: interview the exception, not the process.
Do not ask people to describe their process. They will describe the happy path, because that is what "process" means to them, and it will take an hour.
Ask instead: what went wrong last week? What do you have to fix by hand every month? Which orders do you look at twice? Who calls you when something is stuck, and what are they stuck on? Each answer is an exception, and each exception, followed for one more question, produces its condition, its decision-maker and its inputs.
Three rules from doing this.
Follow the workarounds. Every spreadsheet beside the system, every sticky note, every "I just email Dana" is an exception the system does not handle. The workaround is the documentation, unwritten.
Count frequency. An exception that happens weekly is a process; one that happens yearly is a story. Both go on the page, but the weekly ones are the ones to design for, and the count is what tells a designer whether the exception belongs in the blueprint or in a workflow rule.
Write the decision, not the click. "Open the order, go to the Financial tab, change the hold flag" documents the current tool. "The controller releases the hold if the customer paid within thirty days and the balance is under the limit" documents the business, and survives the tool being replaced.
The two-page format.
Page one is the workflow at the depth of the decision: eight to fifteen steps, each with who, which system, from what information, deciding what. Handoffs marked. That is the whole happy path, and it fits in half a page.
Page two is the exceptions: a table with five columns. The step where it occurs. The condition that triggers it. Who decides. What information they use. What happens next. Ten to thirty rows for a real workflow, ordered by frequency. The rows are the document; page one exists so the rows have somewhere to attach.
A date and an owner at the top of both pages, because the exceptions change as the business does, and the document is wrong six months after it is right. That is fine. A dated document that is wrong is better than an undated one that was never right.
What it is for.
Automation. Every row on page two is a rule an automation has to encode or a gate it has to raise to a person. A workflow with the exceptions listed can be built as a blueprint with its transitions and conditions in days; one without them is built as the happy path, fails on the second day, and is switched off by the people it was meant to help.
AI. An agent given page one will handle the standard case and improvise on everything else, confidently. An agent given page two knows which decisions are its own and which belong to a person, and can raise the ones that do. This is the difference between an AI project that works in a demo and one that works on a Tuesday, and it is why exception documentation is the first artefact we ask for in an AI readiness review.
Continuity. The controller who releases credit holds retires. Page two is what her replacement reads.
Buying software. The exception table is the requirements list. A vendor whose product handles twenty of your thirty rows is a vendor you can evaluate; one whose demo handled the happy path is one you cannot.
Where to start.
Pick the workflow that carries the most money and has the most workarounds around it, usually order to invoice or intake to billing. Spend two half-days with the two people who handle it. Produce the two pages. Then decide, row by row, which exceptions the system should absorb, which it should route to a person, and which should simply stop happening because the condition that causes them can be removed upstream. That last category is the reward: a third of the exceptions on a first table are usually caused by an earlier step that nobody looked at, and the cheapest automation is the one you no longer need.
We do this as the opening of an AI readiness review, and as part of discovery for any build, which you pay for only if you proceed. The build that follows carries a guaranteed estimate, and if we estimate low, we absorb it. The two pages are the part that changes what gets built, and they cost a week.
Know whether your data and processes are ready for AI before you pay for it.
The AI Readiness Review is a 90-minute working session plus a written scorecard across data hygiene, documented process, permissions and ownership. Fixed scope, no obligation. Or see how we approach it.
More on the same problem:
Comments