In short
- An SOP describes the normal case. The judgment lives in the work that is not normal, and almost nobody writes that down.
- Those unwritten rules leave when the person leaves, and the process breaks in ways the documentation never predicted.
- An exception map names the trigger, the criteria, the alternative action and the outcome for each deviation.
- It is not a replacement for the SOP. The SOP handles the routine path and the map handles the departures from it.
- Start with three to five exceptions, chosen by how often they happen and what they cost when handled badly.
Why do standard procedures miss expert judgment?
Because a procedure is written for conditions that hold, and the value of an experienced person is what they do when conditions do not.
So someone in customer service knows a refund for a long-standing account goes through on one email, while the same request from a new account needs a manager. An engineer applies different tolerances depending on the industry and what the contract says. Somebody in sales operations knows which CRM fields genuinely matter and which can wait when a deal is closing on Friday. None of it is written down. It is real, it is consistent, and it is completely invisible to anybody reading the documentation.
So the gap widens quietly as you grow. A new starter follows the written process exactly and breaks an unwritten rule nobody thought to mention. A manager takes over a team and discovers the documented process is not the process. Then a reorganisation moves on the one person who held all the exceptions, and the work starts failing in ways nobody predicted, because the reasons those steps existed were never recorded anywhere.
What does an exception map record that an SOP does not?
Three things, and they are the three that matter.
The first is the trigger, meaning what somebody noticed that told them the standard path was wrong here. The second is the criteria, meaning what they actually checked before deciding. And the third is the alternative, meaning what they did instead and why that turned out to be right. An SOP holds none of those, because an SOP is written as though there is one path.
And take invoice processing. The written procedure says match the invoice to the purchase order, verify the amount, approve the payment. What people actually do has branches: if the amount comes in over the purchase order by more than a set margin it goes to procurement, if the invoice is older than a month it goes to finance for review, and if the supplier is on hold it gets rejected and accounts payable get told. Every one of those is a rule somebody follows. None of them are written down, and the numbers in them are decisions your company made at some point and then forgot it had made.
Scroll the table sideways to see every column.
| Approach | Suits | Captures judgment | Holds up under complexity |
|---|---|---|---|
| SOP | Routine work with few variables | No, it assumes one correct path | Poorly, it breaks at the first edge case |
| Flowchart | Showing the shape of a process | Partly, it shows the branch but not the reason | Fine up to about ten decision points |
| Checklist | Making sure nothing gets missed | No, everything on it looks equally important | Poorly, it cannot show items interacting |
| Decision tree | If-then logic with clear criteria | Yes, the criteria are on the page | Well, where the decisions are hierarchical |
| Exception map | Recording when and why work departs from standard | Yes, trigger and criteria and alternative | Well, and it handles exceptions that interact |
But a flowchart tells you a decision happens without telling you what makes an experienced person go left rather than right. A checklist confirms things got done, not the order or the reason. A decision tree is closer, but it assumes one right answer at each point, and real work often has two defensible answers depending on context. The strongest setup is not one document. It is an SOP for the normal path and a map for the departures, kept next to each other.
How do you build one without tying up the expert for a month?
So, by interviewing rather than writing. You are not drafting a process from first principles, you are getting something out of somebody's head that they have never had to say out loud.
The questions are blunt. When do you ignore the process, and what do you notice that tells you to? What happens if you do not? Then take recent real cases, one at a time, and for each departure write down four things: what triggered it, what you checked, what you did instead, and why that was right. Do that across enough cases and you have a library rather than an anecdote.
One thing catches everybody out. A map built in a single sitting is always incomplete, because judgment is applied in context and nobody can recall every exception on demand. So the first session produces a draft, and the value comes from the second and third pass, where the expert reads their own decisions back and says what is missing. Expect that, rather than treating it as a failure of the interview.
Where to start, and it is not everywhere.Take the three to five exceptions that either happen most often or cost the most when somebody gets them wrong. A complete map is not the goal on day one, and pretending otherwise is how these stall. A map that covers the expensive judgment calls is, and you can grow it from there.
When is an exception map worth the effort?
Three situations, and all three are the same risk wearing different clothes.
So the first is somebody leaving. When a person with a decade of unwritten rules retires or resigns, the map is the difference between a handover and an archaeology project. The second is work moving, to a new team or a new site or a new department, where the map does the job the informal apprenticeship used to do. And the third is automation, because you cannot automate a process whose real rules were never written down, and attempting it is how companies automate the wrong thing confidently.
But there is a fourth benefit nobody sets out to get. Writing the criteria down shows you where your own people disagree. If one person approves a borderline case that another would reject, that was already happening and costing you something. The map is just the first time anybody could see it.
At Strategem this is the work, and we do it for an expert whose exceptions all come back to them, for a founder the team keeps pulling into the same sales moment, and for a champion who has to explain it internally.
What does leaving it undocumented actually cost?
The bill arrives in pieces, which is why it rarely gets attributed properly.
A new starter breaks a rule they were never told and it lands as a customer complaint, a compliance question, or a week of rework. A manager spends their afternoons answering the same what-if question because the person who knew has gone. And a process redesign stalls because nobody can explain why the current workflow looks so inefficient, when several of those inefficiencies are guards against exceptions that were never recorded, and removing them is how you find out what they were for.
And the second cost is inconsistency, which is the one customers notice. Without written rules, different people apply different judgment to identical situations. One approves, another rejects. One ships the order with a small discrepancy, another holds it. Nobody is being careless. There is simply no agreed answer, and the argument about which behaviour was correct gets rerun every time it comes up.
How do you get a first version done?
Small. One process, one person, three sessions.
- Pick a process where exceptions clearly exist and one person handles them best, whether that is onboarding, contract review, troubleshooting or approving suppliers
- Confirm the standard path first, so you know what counts as a departure
- Walk the last three to five real departures and record trigger, criteria, action and outcome for each
- Draw it as a tree, a flowchart or a table of conditions, simple enough to follow in one sitting
- Give it back to the expert and to somebody who does the same job, and fix what they find
So what you have at the end of that is not complete, and it should not pretend to be. It covers the judgment calls that cost the most, and the gaps get filled as people meet cases the map does not answer yet. That is the normal shape of this work rather than a sign it went badly.