Chapter 3
Designing for Exceptions
Chapter 3
Designing for Exceptions
If you don't design for exceptions, you design for failure. This is not a provocation. It is a description of what happens when process design treats the standard path as the only path.
The standard path works until it encounters a condition it was not designed for. At that point the process has no defined response. The people operating it must improvise. The improvisation produces inconsistency. The inconsistency produces risk. The risk compounds until it becomes a problem that is significantly more expensive than the design work that would have prevented it.
Every process includes variability. The input will not always arrive in the expected format. The system will not always behave as configured. The user will not always follow the defined steps. The external environment will not always cooperate. Ignoring this variability does not remove it, it delays its impact and increases its cost.
A process designed only for the happy path is incomplete. It is a description of what should happen, not a design for what will happen. The complete process includes the standard path and the exception paths, the defined responses to the conditions that will deviate from the standard. Without exception paths the process is a plan that works in ideal conditions. With them it is a system that works in real ones.
The distinction between designing for the happy path and designing for the complete process is the distinction between a process that works in testing and a process that works in production.
Key Takeaway:
A complete process is not one that avoids exceptions, it is one that defines how they are handled. The investment in exception design is always less than the cost of managing undefined exceptions in production.
"A process is only complete when it includes its own failure conditions."
MarvinPro_|_March_2026
marvinpro.com
Most processes are designed in a sequence that feels natural but produces gaps. The designer starts with the standard flow, the sequence of steps that converts a normal input into the expected output. Once the standard flow is defined, rules are added to govern it. Exceptions are considered last, if they are considered at all.
This sequence creates a process that is optimised for the scenario it was designed for and unprepared for every scenario it was not. The standard flow works. The rules govern it correctly. But the exceptions, the conditions that fall outside the standard flow, that the rules cannot accommodate, that the designer did not anticipate have no defined handling. They become the operational problems that consume disproportionate time, cost and management attention.
Exception-first design reverses this sequence deliberately.
Instead of beginning with the standard flow and adding exceptions at the end, the designer begins by identifying where the process is most likely to break. What are the scenarios that the standard flow cannot handle? What inputs will the process receive that it was not designed for? What conditions will cause the rules to fail? What decisions will the system be unable to make automatically?
Once the failure conditions are identified, the designer defines how each one will be handled. Who owns the decision? What information is needed to make it? How long should it take? What happens if the decision cannot be made within the defined timeframe? What is the escalation path?
With the exception handling defined, the rules that support those decisions can be designed correctly, not just for the standard scenarios but for the edge cases as well. With the rules complete, the standard flow can be built on a foundation that is stable under variation, not just under ideal conditions.
The result is a process that performs consistently across the full range of conditions it will actually encounter, not just the conditions the designer hoped it would encounter.
Key Takeaway:
Designing from exceptions creates processes that are stable under real conditions, not just ideal ones. The process designed for the break is always more resilient than the process designed for the flow.
"Design for the break, not for the flow."
MarvinPro_|_March_2026
marvinpro.com
When exceptions occur, decisions must be made. The process has encountered a condition it cannot handle automatically. Someone or something must determine what happens next.
There are two mechanisms for making these decisions and understanding the difference between them is essential to designing exception handling that works at scale.
Decision logic is the set of predefined rules that govern how specific exceptions are handled. It is automated or system-driven. It operates consistently and at scale without requiring human intervention. When a transaction exceeds a defined threshold, the system routes it to a higher approval level automatically. When a document fails a validation check, the system returns it to the submitter with a defined error message. When a request falls outside the standard categories, the system escalates it to the defined exception handler.
Decision logic is scalable, consistent and fast. It works well for exceptions that are frequent enough to justify defining the handling in advance and predictable enough to be resolved by a rule rather than a judgment.
Decision authority is the human capacity to make judgment calls that rules cannot accommodate. It is flexible, context-sensitive and capable of handling scenarios that no rule anticipated. When a customer situation is genuinely unique. When the right answer depends on information that the system cannot access. When the decision requires experience, empathy or commercial judgment that no algorithm can replicate.
Decision authority is essential for the exceptions that fall outside the scope of any predefined rule. But it is expensive, it requires people with the right knowledge and the right mandate, and it does not scale in the way that decision logic does.
The challenge in exception design is calibrating the balance between the two. A process that relies entirely on decision logic becomes rigid, it handles the defined exceptions well and fails on everything else. A process that relies entirely on decision authority becomes inconsistent and expensive, every exception requires a human decision, and human decisions vary.
The well-designed process defines both the exceptions that decision logic can handle and the exceptions that require decision authority. It makes the boundary between them explicit. It ensures that the people with decision authority are available, informed and empowered to make decisions within the defined scope.
Key Takeaway:
Processes must define both what can be decided by rules and what must be decided by people. The boundary between decision logic and decision authority is itself a design decision and one of the most important ones in exception handling.
"Where rules end, authority begins. If neither is defined, nothing moves."
MarvinPro_|_March_2026
marvinpro.com
Rigid processes break under pressure. The process that cannot accommodate any deviation from the standard path will encounter a condition it cannot handle and when it does, the only options are to stop, to escalate or to bypass the process entirely. None of these are good outcomes.
Uncontrolled flexibility creates a different problem. The process that accommodates any deviation, in any way, by anyone, produces inconsistency. Different people handle the same scenario differently. The audit trail becomes unreliable. Compliance becomes impossible to demonstrate. The process exists on paper but not in practice.
Controlled flexibility is the design principle that sits between these two failure modes. It defines where deviation from the standard path is permitted, who can approve it, how it must be documented and when a recurring deviation triggers a review of the standard path itself.
Controlled flexibility means that when an operator encounters a scenario the standard process cannot handle, they have a defined channel for handling it, a documented exception path that records what happened, who decided and why. The deviation is not bypassed or hidden. It is handled through a controlled mechanism that maintains the audit trail, preserves consistency and generates the data needed to assess whether the exception should be incorporated into the standard process.
Over time, controlled flexibility does something powerful. It converts the informal adaptations that people make when the process cannot handle their situation, the workarounds, the shadow processes, the undocumented decisions into formal exception paths that the organisation can see, govern and improve. The shadow processes become visible. The workarounds become defined. The organisation gains a complete picture of how its work is actually getting done, not just how the standard process says it should get done.
Key Takeaway:
Flexibility without control creates inconsistency. Control without flexibility creates failure. The goal is not to eliminate deviation, it is to control it, document it and use it to improve the process.
"The goal is not to eliminate deviation, it is to control it."
MarvinPro_|_March_2026
marvinpro.com
In a large organisation operating a billing process across multiple markets, a specific customer category could not be charged through the standard system. The system had no defined path for these customers. They fell outside the normal billing logic.
The problem was known. The responsible department had identified it. But resource limitations meant they were unable to resolve it within any near-term timeframe. The official response had been acknowledged, wait for the responsible department to find capacity. The uncharged customers continued to accumulate.
That response was not accepted.
Instead the problem was treated as a design input. If the system cannot charge these customers today, what needs to be in place for the moment it can? The decision was made to collect all charge details systematically, including a three month backlog that already existed, and maintain that collection consistently going forward.
Seven months later a robotic process was deployed that could handle the previously unsupported customer category. Because the charge details had been collected and maintained throughout, ten months of accumulated charges were processed successfully at the point of resolution.
No revenue was permanently lost. No customer was missed. The exception had been designed for, not by fixing the system immediately, but by ensuring that when the fix arrived, everything was ready.
The process did not wait for the system. The system caught up with the process.
"Design for the fix before the fix exists. When it arrives, everything should already be ready."
MarvinPro_|_March_2026
marvinpro.com
Chapter Outcome:
Processes are not defined by their standard flow.
They are defined by how they adapt when the standard flow cannot handle what it encounters.
Designing for exceptions is not an enhancement to a complete process. It is the difference between a process that works in testing and a process that works in production. Exception-first design, clear decision authority, controlled flexibility, these are not advanced process design concepts. They are the foundational requirements of any process that will operate reliably at scale.
The process that was designed for the break will hold when conditions change. The process that was designed only for the flow will break predictably, expensively and at the worst possible time.
"A process designed only for the ideal scenario is incomplete. Design for what will go wrong and the process becomes reliable. Ignore it and the exceptions design themselves."
MarvinPro_|_March_2026
marvinpro.com