Document the Exceptions First
Open any procedure written by a business about its own work. It will describe the straightforward version.
Order arrives, order gets processed, order ships. Enquiry arrives, enquiry gets a reply.
That version is accurate and almost useless, because the straightforward case is the one nobody needed help with.
Where people actually get stuck
Not on the normal path. On the day the address doesn't match, the item is out of stock, the customer replies to a message from four months ago, the payment half-goes-through, or someone asks for something you've done twice and nobody remembers how.
That's when a person stops and asks. And asking is the cost the documentation existed to remove.
A procedure covering only the normal case saves nobody any time, because the normal case is already fine.
Why it happens
They're harder to write. The normal path is a sequence. Exceptions are a branching set of conditions, and each one needs a decision that may never have been articulated.
They're invisible when you're not doing the work. Someone writing a procedure from a desk describes the shape of the process. The exceptions only appear when you watch, or when you go through real cases — including the ones that went wrong.
They feel like edge cases. Individually they are. Collectively, in most businesses, they're a large fraction of the work. Ask anyone who does the job what proportion of their time goes on the straightforward version. The answer is rarely most of it.
What it costs to leave them out
The procedure gets abandoned. Someone follows it, hits a case it doesn't cover, asks a person, and learns that asking is more reliable than reading. They don't go back.
Handover stays slow. A new person can handle the easy cases from day two, which was never the bottleneck. The bottleneck is the other third, and that still takes months.
Automation breaks. A workflow built from a procedure that only describes the normal path will encounter exceptions and fail, or worse, process them as if they were normal.
Inconsistency goes undetected. Without a documented exception, two people handle the same unusual case differently and nothing flags it.
How to find them
Ask for the case that went wrong
When you review real cases, insist that at least one is a failure. People offer their best examples by default; the failure is where the information is.
Chase every "usually"
"Usually we just send the confirmation." Usually. What's the other case?
"Normally that's fine." Normally. When isn't it?
These hedges mark exceptions the speaker knows about and doesn't think are worth mentioning.
Watch for the hesitation
When someone demonstrating a process pauses, scrolls back, or checks something — that's a decision point. Ask what they were checking for.
Ask what makes a case annoying
"What kind of job do you dread?" is a better question than "what are the exceptions?" People can answer it immediately, and the answer is a list of exceptions with the costs attached.
How to write them
Not as a wall of conditions in the steps. That makes the procedure unreadable and buries the normal path.
Two sections:
Decisions — the branches that occur regularly, as a table: situation, rule. These are part of the process, not deviations from it.
| Situation | Rule |
|---|---|
| Order over £500 | Manual review before dispatch |
| Delivery address differs from billing | Confirm by phone before dispatch |
| Customer has an open complaint | Hold, notify account owner |
Exceptions — the genuinely unusual, with what to do instead.
Item discontinued mid-order → offer the nearest alternative from the same category; if declined, refund in full and flag to purchasing.
The distinction matters: decisions are expected branches, exceptions are departures. Mixing them makes both harder to find.
The test
If a procedure has no exceptions listed, it hasn't been observed closely enough.
Every real process has them. A document without them was written from a description rather than from watching the work.
It's the quickest quality check available on any procedure, including ones you wrote yourself.
Try it in the other order
Next time you document something, start with the exceptions.
Ask what goes wrong, what's unusual, what requires a decision. Write those down first.
Then fill in the normal path around them — which takes twenty minutes, because the normal path was never the hard part.
The resulting document is shorter, more useful, and more likely to be read a second time.
The normal case is the part people already manage. Document the other part.
Want procedures that cover the cases people actually get stuck on?
A free systems audit starts by watching the real work, including the cases that go wrong.