KM-301e · Module 1

Decision Points vs. Linear Steps

3 min read

Most process documentation is written as a linear list of steps. Most real processes are not linear. They contain decision points — moments where the correct next action depends on the current state of the world. Linear documentation handles linear processes adequately. But linear documentation applied to a branching process hides exactly the places where the person executing the process needs the most help: the moments where they must decide, and where the decision determines the outcome.

Do This

  • Map the process before documenting it — identify every decision point, condition, and branching path
  • Document decision criteria explicitly: "if X, then Y; if Z, then W" at every branching point
  • Use decision trees or flowcharts for processes with more than two decision points
  • Test the documented decision logic against known edge cases before publishing

Avoid This

  • Document a branching process as a linear step list — the branches are where the process is most likely to fail
  • Use vague language at decision points: "as appropriate" or "if necessary" are not decision criteria
  • Assume the reader knows the conditions — name them explicitly even when they seem obvious
  • Omit the error paths — the most common reason for escalation is not knowing what to do when the expected path breaks
  1. Identify Decision Points Walk through the process and mark every point where the next step depends on a condition — a state, a value, an outcome, an exception. These are the decision points. If the process has zero decision points, it is a linear procedure. If it has more than eight, it is complex enough to require a flowchart.
  2. Define the Decision Criteria For each decision point, define the conditions precisely: "if the customer's contract value is above $50,000, route to enterprise review. If below, route to self-service onboarding." Vague criteria — "use your judgment" — are not documented criteria. They are gaps where the documentation abdicates its responsibility.
  3. Document Both Paths Every decision point has at least two outcomes. Both must be documented. Documentation that covers only the expected path treats the exception as someone else's problem. In practice, the exception is the most common reason a process breaks down and the documentation gets abandoned.