How to Document Decisions, Exceptions, and Rework

Draw a process map from memory and you will almost always draw the happy path: the case that arrives clean, moves through each step without incident, and finishes on schedule. That map is true, in the sense that it describes something that really happens. It is also close to useless on its own, because in most real processes the happy path is a minority of cases. Invoice approval, for instance, mostly does not run smoothly. Some invoices lack a purchase order reference, some exceed an approver's authority limit and need to go up a level, some get queried by the approver and sent back to the requester for clarification. The map that matters is the one that shows all of that, not just the clean case.

Writing decision rules that are actually testable

A decision point in a process is only well documented if someone reading the description could apply the rule themselves to a new case and get the same answer a trained employee would. "Approver checks if the invoice looks right" is not a testable rule. "Approver checks the invoice amount against the purchase order and approves if the variance is under five percent, otherwise routes to the requester for explanation" is testable, assuming that figure is accurate to how the team actually works. Getting to that level of precision usually takes more than one conversation, because people describe their own judgment in vaguer terms than they actually apply it. Asking for two or three real recent examples of the decision, rather than an abstract description of the rule, is often the fastest way to get to something testable.

Naming branches and estimating their frequency

Every fork in a process should have named branches, not just an arrow pointing off the main line. For invoice approval, naming the branches might look like: clean approval, approval with query, escalation for authority limit, and rejection for missing documentation. Once the branches are named, ask roughly what share of cases takes each one. Precision is not the goal here, since most teams do not have exact figures for this without pulling data. A reasonable estimate (roughly a quarter of invoices get queried, for example) is enough to change how the process gets prioritized for improvement, because it tells you the query path is not a rare edge case, it is a substantial share of the workload.

Distinguishing an exception from a variant

A variant is a different but expected path through the process, one that happens regularly enough to be considered a normal part of how the process runs. An exception is genuinely unusual: something the process was not really designed to handle gracefully, and typically needs a person to intervene with judgment rather than following a documented rule. In claims processing, a claim that requires additional evidence is a variant, since it happens often enough that the process has a built-in step for it. A claim connected to a suspected fraud investigation is an exception, since it usually gets pulled out of the normal flow entirely and handled by a specialist team under different rules. Treating every unusual case as an exception inflates the exception list and hides which paths actually deserve a properly designed variant path of their own.

Capturing correction loops and where work returns to

Rework is what happens when a case fails a check and has to go back to an earlier step to be fixed. This is different from an exception or a variant because the case is not taking an unusual path, it is going backward. For invoice approval, rework happens when an approver queries an invoice and it returns to the requester, who corrects it and resubmits. The important detail to document is exactly where it returns to and what changes before it moves forward again. Does it go back to the original requester, or to a shared queue that anyone on the team might pick up? Does it re-enter the approval step from the start, or does the approver just need to confirm the specific fix was made? These details matter enormously for cycle time, because a rework loop that adds a full re-approval cycle is much more expensive than one that only requires a quick confirmation.

Rework is consistently the most under-documented part of a mapped process, because it is boring to describe and slightly embarrassing to admit happens often. Teams will readily describe the escalation path for a large invoice, since that sounds like proper process design, but they are less likely to volunteer that a third of invoices get bounced back at least once for a missing cost center code. Asking directly, "what causes something to get sent back, and how often does that happen," tends to surface this far more reliably than waiting for it to come up naturally.

Decision, branch, exception, and rework compared

How Processfix handles this

In Processfix, decisions, branches, exceptions, and rework loops are captured directly in the swimlane editor as part of the process model, and the simulation runs hundreds of cases through those branches according to the frequencies entered, which is what allows a bottleneck caused by a rework loop to show up in the results rather than being hidden inside an average. The frequencies and rules still come from the user, based on what they know about the real process. Processfix models what is described and estimates the effect of changes, it does not independently verify that a decision rule is applied consistently in practice.