A decision map is the written record of every decision a workflow contains, what each one requires in order to be made well, and who or what is permitted to make it. It is the first thing we produce in any engagement and the thing the client owns outright. Before a decision map exists there is nothing to build against, because a workflow described as a sequence of steps hides the judgment that actually determines the outcome.
Why the map comes before the build
A workflow looks like a sequence of clicks and is actually a chain of decisions. Automating the clicks produces something brittle that breaks the first time an interface changes. Automating the decisions requires knowing what each one needs: which inputs, which rules, which thresholds, and which exceptions have historically mattered.
The map is also where disagreement surfaces safely. Two people who both perform the same workflow will describe the same threshold differently, and that difference is better settled in a document than discovered in production. Most of the value of discovery is in those arguments.
What a decision map contains
Every decision, named
Not the steps, the decisions. Each written as the question actually being answered: whether this invoice matches, whether this request is routine, whether this account is worth a rep’s afternoon.
Two ratings per decision
How much judgment the decision requires, and what happens if it is wrong, including whether the action can be reversed. The two are independent, which is the part most people get wrong.
An autonomy level and an owner
Runs independently, drafts for approval, or remains human — with a named person accountable for the decisions in the third category and for reviewing the second.
What the map is used for afterwards
The map is not a discovery artefact that gets filed. It is the reference for every later change: when a threshold moves, when a new exception type appears, or when the coworker is trusted with something it previously only drafted, the change is made in the map first. That record is also what makes the system portable — you can hand it to your own team or another provider and they will know what the coworker is supposed to do, and why.
Read more in our blog: Judgment and Stakes Are Two Different Axes and How to Choose the First Workflow.