Decision Points: The Part of the Process Nobody Documents

Your SOP says "confirm the job is paid." It does not say that a card payment posts the second it clears, while a check is not real until somebody chases the deposit. That gap is a decision point, and it is the part of the process nobody writes down. To document decision points in a process, name the fork, write the rule that covers the normal case, then write the exception and the person who owns it.

Steps tell you what to do. Decision points tell you what to do when it depends.

Open any procedure and count what is in it. Almost all of it is sequence: log in here, click this, send that, mark it closed. That part is easy to write, because you can do it by watching a screen.

The hard part is every place the process asks a person to choose. For every process we capture three things: why it exists, where the judgment calls live, and how the work actually gets done screen by screen. Most documentation has one of the three, and the missing middle is what breaks.

A process almost never fails at its steps; it fails at the forks nobody thought to write down.

In one field services operation, the target was 4,000 dollars per van per day. Mid-conversation, out loud, it became 6,000. That number tells a dispatcher which jobs to chase and when a day is going badly, which makes it a decision rule with no home.

What is a decision point?

A decision point is any moment in a process where the right action depends on context, so the work branches and a person has to choose. It is not a step with an option bolted on. A step has one correct output every time you run it.

A decision point has more than one, and which one is right depends on something the document never mentioned: the payment method, the customer, who is on the truck. The person doing the work resolves it in half a second. The document, if it says anything, says "use your judgment."

That is why forks belong at the center of process documentation, not out at the edges. A procedure that lists only steps is a map with every intersection left blank.

Find the forks: the four questions that surface them

You will not find decision points by rereading the SOP you have, because the forks were invisible to whoever wrote it. Ask these four questions while somebody does the work in front of you.

1. Watch for the wait. Where does the work stop? Every pause is a person deciding whether to proceed. In that same field services company, anyone can mark a job paid in cash with nothing in the bank, so "is this job paid" is two questions wearing one label.
2. Compare two people. Where do two people doing the same job do it differently? In a nonprofit's department by department sessions, colleagues kept discovering mid-session that they each ran the same task their own way.
3. Track the handoff. Where does someone outside the process get pulled in, and what condition pulls them in at that moment? Handoff timing is almost always an inherited rule with no author.
4. Ask what goes wrong. What are the exceptions, and what does each one cost? A staffing branch ran a taxonomy for escalated cases: injury, altercation, theft, damage, intoxication, plus a do-not-return flag that is not always negative. Those rules lived in one manager's head until he left.

All four questions are about the work, not the document, which is why we record the practitioner instead of the manager: managers remember the version they designed, the operator knows the version that survives customers. The same discipline that surfaces a process that only lives in someone's head surfaces the forks inside it.

How to document decision points in a process: the rule, the exception, the owner

Four lines per fork is enough, under the step where the choice happens. Not a flowchart, not a policy memo.

1. Name the trigger. Write the observable condition that makes the fork appear, in the words the team already uses. "Customer paid by check" is a trigger. "Sometimes payment is unclear" is not.
2. Write the default rule. One if-then sentence a person can act on without asking anyone. If it takes two sentences, you probably have two forks.
3. Write the exception and its owner. Say what breaks the rule and name the role that decides when it does. If a rule has no named owner for the exception, it is not documented, it is a suggestion.
4. Date every number. Any threshold gets the figure, the date it was set, and the person who can change it. Otherwise the number moves verbally and nobody can tell whether the team missed or the target did.

Here is what that looks like on four common forks.

The right column is barely longer than the left, and written this way a fork folds into a plain SOP template as a short block under its own step. The cost is real: every rule you write is one somebody has to keep current, so a fork that moves every quarter belongs in a dated note, not in the procedure.

Why does finance come in here and not there?

That question came from an owner watching his own operation on a screen for the first time in years. Sequencing is a decision, not a fact: where a function enters is a rule somebody chose, for a reason nobody still in the building can name.

The cost of leaving it unwritten is not theoretical. After a key person left, one owner covered payables himself and found 500 to 800 dollars leaking every week from skipped audits, missed part deductions, and overpayments, near 10,000 dollars a month by his own math. None of it was theft. All of it was rules that walked out with him.

Write down not just who is involved, but the condition that pulls them in. Finance touches the job after it closes and before commissions run. The routing manager gets the call when two jobs need the same tech. Once the condition is on the page, the handoff stops depending on memory.

Two people, one SOP, two different results

Two people follow the same SOP. One gets it right every time. The other cannot get it right to save his life, and the difference is never in the steps, which are identical on both screens.

Your best performer is running a private rulebook nobody has ever read.

What separates them is roughly ten or twelve principles running unconsciously in the strong performer's head, put there by a first boss, a customer who blew up, a mistake that hardened into a personal law. Ask him and he will say he just knows. Pulling those out is its own discipline, covered in how to capture why your best people get it right.

A documented decision point is one of those principles turned into a sentence somebody else can use.

Decision points are what a new hire cannot shadow their way to

When onboarding is "shadow someone for a while," new hires take months to become useful, and the reason is structural. A shadow sees the choice happen. He does not see the reason, because it took half a second and was never said out loud.

That is the trap in documenting an expert who cannot explain what they do: the fastest performer is often the worst narrator of his own work. He is not hiding anything. The rule stopped being conscious years ago.

One operations lead put the other half of it plainly: the more a process depends on remembering, the more of it gets skipped. You fix that by writing the fork where the person hits it, not with a reminder.

---

Put the fork in the document, not in someone's head

Take the process your team interrupts you about most and do not rewrite it. Read it once and mark every place a person has to choose. You will recognize the forks, because they are the questions people bring to you.

That is the difference between a document and a system: a system answers the question you were about to be asked. At The Systems Effect we treat the forks as a deliverable in their own right, which is why our procedures do not become SOPs nobody actually follows.

You will find them faster than you expect. You have been making those calls for years.

Frequently Asked Questions

What is a decision point in a process?

A decision point is a moment where the right action depends on context, so the process branches and a person has to make a judgment call. Payment method, customer history, and who is available are common triggers. These are the moments where processes break down when nobody documents them.

How do you document a judgment call?

Write four lines under the step where the choice happens: the trigger, the default if-then rule, the exception, and the role that owns it. Keep the default rule to one sentence someone can act on without calling anyone. Give any number in the rule a date and an owner, so a moved target cannot pass as a missed one.

Why do two employees following the same SOP get different results?

Because the steps are not what separates them. The strong performer is running ten or twelve principles nobody wrote down, formed by experience rather than training, and the SOP captures none of them. Turning the important ones into written decision rules is what closes the gap.

How many decision rules should one SOP have?

Fewer than people expect. In the processes we map, a normal one produces three or four genuine forks, and something complex like routing might produce eight. Thirty means you documented preferences, not decisions. A fork earns its place when getting it wrong costs money, time, safety, or a customer.

Who decides what the right call is?

One person, not a committee. Pick the practitioner who does the work well, is still doing it, and wants to take part, then get to a first 80 percent with them. Let the peer group tear it apart afterward, which is how you end up with a rule people feel they wrote.