Process Mapping for Knowledge: Documenting vs. Capturing

There is a gap between describing a process and capturing it, and most process documentation falls on the wrong side of that gap. Describing a process tells someone the steps at a level of abstraction that is useful for understanding what happens but insufficient for doing it. Capturing a process gives someone enough information that they can execute it to the required standard without asking for help.

The difference shows up in the detail density. A process description says 'review the customer contract for renewal eligibility.' A process capture says: open the customer record in Salesforce, navigate to the Contracts tab, filter for contracts expiring within 90 days, check each contract against the renewal criteria in the pricing reference document, flag any contract with an ARR above $50K for manager review, and document the review outcome in the contract notes field using the standard renewal status codes from the reference table. Same process. Radically different utility for someone who has never done it.

Process documentation for knowledge transfer has a specific goal: the document should allow a competent person with no prior experience in this process to execute it correctly on their first solo attempt. That is a higher bar than most process documentation is written to meet. Most process documentation is written for people who have done the process before and need a reminder, or for auditors who need proof that the process exists. Neither of those audiences needs capture-level detail. Knowledge transfer does.

The practical test for whether process documentation achieves the capture standard is to give it to someone who has never done the process and watch them attempt it. Where they get confused, where they have to guess, where they ask questions — each of those is a gap in the documentation. The observer does not answer the questions. They note the gaps and fix the documentation.

1. The Right Level of Abstraction Process documentation for knowledge transfer should be written at the level of the task, not the outcome. Not 'ensure compliance with the security policy' but the specific actions that constitute compliance: which configuration to check, what value it should have, where to record the result, and what to do if the configuration does not match the required value. Every step that requires the performer to know something unstated is an abstraction that needs to be brought down a level.
2. Preconditions and Inputs Before the first step: what does the performer need to have, know, or have access to? What systems must be accessible? What prior steps must have been completed? What decisions must have been made? Preconditions are almost always omitted from process documentation and are the first thing a new performer stumbles on — they start executing and discover on step 4 that they needed something they do not have.
3. Decision Points and Branches Where does the process diverge based on a condition? 'If the contract value exceeds $X, do Y. If not, do Z.' Documenting decision points explicitly is the difference between a linear process description and a captured process that handles the real-world variation. Decision points are where expertise lives — the novice follows the linear path and fails at the exception. The expert navigates the branches automatically. Capture the branches.
4. Verification and Error Handling After each significant step: how does the performer know it worked? What does success look like? What does failure look like, and what should the performer do if the step produces an unexpected result? Verification steps are the difference between a process document and a runbook. Without them, a performer who gets an unexpected result has no guidance — they either proceed incorrectly or stop and ask for help.