Skip to content

Exception Handling Playbook

Reference artifact — instantiates Response Repertoire Expansion

Turns a recurring class of exceptions into named, written procedures, so staff select a known response instead of improvising each disturbance from scratch.

An Exception Handling Playbook captures, for a bounded family of recurring exceptions, the response to each one — its purpose, steps, actors, outputs, and limits — so the same disturbance is not re-solved from zero every time it appears. Its distinctive content is the response itself for the non-routine-but-familiar cases: the judgment-laden "when the weird-but-known thing happens" situations, organized as a library of named exception → procedure pairs. It is the substance of the response, authored from real recurring incidents, with each entry stating where its own scope ends.

Example

At an airline, irregular operations (IRROPS) used to mean improvisation: when a weather cancellation stranded a wide-body's worth of passengers, each gate agent rebooked differently and some quietly broke fare rules. An exception-handling playbook names the exception classes — weather cancellation, mechanical, missed-connection cascade, crew timeout — and pairs each with a procedure: the reaccommodation priority order, the hotel and meal authority limits, the misconnect rebooking script, and the point at which a case exceeds the agent's authority and must go to the duty manager. A stranded-passenger event that used to be twenty separate improvisations becomes one named, bounded response, and every agent knows exactly where their authority stops.

How it works

The playbook enumerates a case family and pairs each named case with an executable procedure and an explicit boundary. It is written from incidents that actually recurred, not hypotheticals, and each entry declares what it does not cover, so a case that falls outside gets routed to escalation rather than jammed into the nearest-fitting procedure. Its contribution is coverage and consistency for a known exception class — collapsing improvisation variance into a single best-known response.

Tuning parameters

  • Case granularity — few broad procedures or many specific ones. Fine-grained entries fit precisely but bloat the library and slow lookup; coarse ones stay flexible but under-specify the response.
  • Prescriptiveness — step-by-step script versus principles plus judgment. Tight scripts let novices execute fast but fail on off-pattern cases; loose ones need expertise to run.
  • Boundary tightness — how much an entry may handle before it must escalate. Wider local scope resolves more cases in place but risks unsafe overreach.
  • Coverage discipline — how a new exception class earns a playbook entry rather than staying in improvisation.

When it helps, and when it misleads

Its strength is that it collapses improvisation variance, spreads the best-known response to everyone, and encodes where authority ends. Its failure mode is that a playbook is only variety for the exceptions it lists: a genuinely novel case gets forced into the nearest entry — applying an ordinarily-sound rule to a situation where its conditions don't hold, a rule-based mistake.[1] It also rots as the environment shifts underneath it. The classic misuse is writing an exhaustive playbook nobody consults, or following an entry past the point it has stopped applying. The discipline is to mark each entry's boundary explicitly and route out-of-pattern cases to escalation and to review — which mints new entries — rather than mis-fitting them.

How it implements the components

  • response_option_specification — each entry is a specified response: purpose, steps, actors, outputs, and limits.
  • scenario_library — the organized, named set of recurring exception cases the playbook covers.
  • boundary_and_escalation_rule — each entry states what it may handle and the point at which a case must move to escalation.

It does not encode the runtime logic that picks which entry a live case selects — that is Decision Tree Update — and it does not keep the collection curated, owned, and de-duplicated over time; that is Runbook Library Update.

  • Instantiates: Response Repertoire Expansion — it supplies the documented content of the new responses the repertoire adds.
  • Consumes: After-Action Repertoire Review supplies the recurring exception classes that earn a new entry.
  • Sibling mechanisms: Decision Tree Update · Runbook Library Update · Cross-Training Program · After-Action Repertoire Review · Competency Matrix Update · Controlled Pilot · Job Aid Checklist · New Service Tier · Scenario Drill · Tool Capability Addition · Triage Protocol Update

Notes

A playbook documents a response but does not enable it: under real pressure people still need to have practiced it (Scenario Drill) and to have a point-of-use prompt (Job Aid Checklist). A thick, correct playbook that no one has rehearsed is a common false comfort.

References

[1] In James Reason's error taxonomy, applying an ordinarily-sound rule to a situation where its conditions don't hold is a rule-based mistake — distinct from a slip or lapse. A playbook makes such mistakes easier precisely because it makes the rule so ready to hand. ↩