Chapter 2
What Is an Exception (Really)
Chapter 2
What Is an Exception (Really)
An exception is not a mistake. It is not a failure. It is not evidence that something went wrong. An exception is a condition the process was not designed to handle.
This distinction matters more than it appears to. When an organisation treats exceptions as mistakes, it responds to them by looking for someone who did something wrong. When it treats them as design gaps, it responds by improving the process. The first response produces blame. The second produces improvement.
Every process defines what should happen. It describes the standard path, the sequence of steps that converts an input into an output under normal conditions. An exception defines what the process cannot handle. It is the scenario that falls outside the standard path, the input the process was not designed to receive, the condition the rules cannot accommodate, the decision the system cannot make automatically.
If a scenario is not defined, it becomes an exception. If a rule cannot be applied, it creates an exception. If a decision cannot be made within the process, it escalates as an exception. None of these are failures of the people operating the process. They are gaps in the process design.
The organisation that understands this does not ask who caused the exception. It asks what the process failed to define. The answer to that question is always more useful and always more honest.
Key Takeaway:
An exception is not an error in the process, it is a signal that the process definition is incomplete. The correct response to an exception is not to find fault. It is to close the gap.
"An exception is not what went wrong. It is what was never defined."
MarvinPro_|_March_2026
marvinpro.com
Not all exceptions are the same. They exist at different levels of predictability, frequency and impact and they require different responses.
The most manageable exceptions are the known ones. These are deviations from the standard process that have been encountered before, documented and given defined handling. A standard escalation flow for a customer complaint that cannot be resolved at the first level. A manual approval process for a transaction that exceeds the automated approval threshold. A defined procedure for handling a document that arrives in an unsupported format. Known exceptions are part of the process design, they are exceptions in name only. The process knows they will occur and knows exactly what to do when they do.
Unknown exceptions are more challenging. These are scenarios that have not been encountered before or have been encountered but never documented. They require real-time decision-making by someone with the knowledge and authority to resolve them. Unknown exceptions are inevitable in any complex environment. The goal is not to eliminate them but to convert them into known exceptions as quickly as possible by documenting the scenario, the decision made and the reasoning behind it, so that the next occurrence is handled consistently rather than individually.
System exceptions occur when the technology fails to process a transaction correctly, a validation error, a configuration mismatch, an integration failure. These exceptions are often the most visible because they produce error messages, failed transactions or system alerts. They are also often the easiest to diagnose because the system itself records what went wrong.
Process exceptions occur when the process design cannot accommodate the scenario, the rules do not cover it, the approval flow does not include it, the workflow does not route it correctly. These are harder to diagnose because the system may process the transaction without error while producing an incorrect outcome.
Human exceptions occur when judgment, interpretation or error introduces a deviation from the defined process. These are the most complex to manage because they require both a process response and a human development response, the process gap must be closed and the person must understand what the correct handling is.
Key Takeaway:
Exceptions are not a single category, they are a spectrum of predictable and unpredictable conditions that require different responses. The organisation that treats all exceptions the same will manage none of them well.
"Not all exceptions are equal. Some are managed. Others define your limits."
MarvinPro_|_March_2026
marvinpro.com
A single exception, handled correctly, costs the organisation very little. It requires a decision, some manual effort and a brief delay. If the exception is documented, it costs even less the next time because the decision has already been made.
An exception that is not handled correctly costs more. It may require rework, escalation or customer contact. It may create a downstream impact in a process that depends on the output of the one that produced the exception. The cost is still contained but it is higher than it needed to be.
An exception that is not handled at all costs the most. It sits unresolved, accumulating downstream consequences, until someone notices that something is wrong. By then the cost of resolution is significantly higher than the cost of the original exception because the problem has compounded.
This progression from exception to incident to crisis follows a consistent pattern. A single exception is a localised deviation from the standard process. An incident is a disruption that impacts operations usually the result of multiple unresolved exceptions converging, or a single high-impact exception that was not caught early enough. A crisis is a systemic breakdown affecting multiple processes simultaneously, almost always the result of incidents that were not contained before they spread.
The relationship is hierarchical and directional. Exceptions accumulate into incidents. Incidents escalate into crises. The intervention point that costs the least is always the earliest one at the exception level, before accumulation begins.
This is why exception management is not a support function. It is a risk management function. The organisation that manages its exceptions well is actively preventing the incidents and crises that unmanaged exceptions produce.
Key Takeaway:
A crisis is not a sudden event, it is the result of unmanaged exceptions accumulating over time. Every exception that is resolved at the exception level is an incident that never happened and a crisis that never arrived.
"Crises don’t start at scale. They start as exceptions no one resolved."
MarvinPro_|_March_2026
marvinpro.com
Every organisation has processes it knows about and processes it does not know about. The processes it knows about are documented, governed and visible to management. They appear in process maps, system configurations and standard operating procedures. They are the official version of how work gets done.
The processes it does not know about are the workarounds, the informal adaptations that people create when the official process cannot handle what they are facing. Manual adjustments that bypass system validations. Informal approvals that substitute for formal ones. Local variations developed by teams who found a better way to handle a specific scenario but never told anyone outside their team. Undocumented decision logic that exists in the heads of experienced people and nowhere else.
Workarounds are created with good intentions. They exist because the official process has a gap and the people operating it found a way to fill that gap. They keep the operation running. In the short term they are a positive signal, they are evidence of capable, adaptive people who care enough to solve problems rather than report them and wait.
The problem is what they become over time. A workaround practised consistently becomes a habit. A habit adopted by a team becomes a shadow process, an undocumented way of working that exists alongside the official process. The shadow process creates inconsistency because not everyone knows about it. The inconsistency creates risk because different people handle the same scenario differently. The risk compounds because nobody has a complete picture of how the work is actually being done.
The organisation believes its process is working. Its data is being processed. Its customers are being served. Its transactions are closing. But the process that is producing those results is not the official process. It is the official process plus a collection of shadow processes that nobody has mapped, nobody has governed and nobody has assessed for risk.
Key Takeaway:
Workarounds do not fix exceptions, they hide them, creating uncontrolled processes that introduce inconsistency, risk and organisational fragility. Surfacing and resolving workarounds is not an audit function. It is a process maturity requirement.
"When people stop following the process, a new process is created without control."
MarvinPro_|_March_2026
marvinpro.com
In a global service environment supporting a research organisation, access management was a critical and tightly controlled process. Every user account, every security group, every mailbox had a defined request path. The process was clear. The rules were documented. The system was mature.
Until it wasn't.
The standard process handled the predictable requests well, new starters, leavers, role changes. These were known exceptions with defined handling. The process absorbed them without difficulty.
The complexity emerged at the edges.
Researchers moving between projects needed access combinations that no existing security group covered. Temporary contractors required mailbox access that crossed organisational boundaries. System accounts needed permissions that the standard request form could not capture. Each of these was an unknown exception — a scenario the process had not been designed to handle.
The instinctive response in many organisations would have been to escalate everything unusual, creating bottlenecks at senior level. Instead a different approach was taken.
Each unusual request was treated as a signal. What category does this belong to? Has this occurred before? If it has, why is there no defined path for it? If it hasn't, what is the correct handling and how do we document it so the next occurrence is a known exception rather than an unknown one?
Over time the unknown exceptions decreased. Not because the environment became simpler, it did not. But because each exception was converted into a defined scenario with a repeatable resolution.
The process became more complete with every exception it absorbed.
"An unknown exception handled once is a known exception waiting to be defined."
MarvinPro_|_March_2026
marvinpro.com
Chapter Outcome:
Exceptions are not anomalies. They are structural signals.
Understanding what an exception is a gap in process design, not a failure in execution changes how the organisation responds to them. It changes the question from who caused this to what was never defined. It changes the response from blame to improvement.
The spectrum from known to unknown exceptions, from exception to incident to crisis, from workaround to shadow process these are not abstract concepts. They are the operational reality of every organisation that has ever run a complex process at scale.
Understanding them is the foundation of designing for them. Which is where the next chapter begins.
"An exception is not a problem with the transaction. It is information about the process. The difference between those two interpretations determines whether the organisation learns or repeats."
MarvinPro_|_March_2026
marvinpro.com