Playbook
Exception queue triage workflow
Route taxonomy-owned exceptions to support, treasury, engineering, or finance with SLAs defined by your policy—not ours.
01
Objective
Route exception queue items to the correct owner with required evidence—preventing informal overrides and operational drift.
02
Prerequisites
- Exception taxonomy published internally.
- Queue filters by class, age, and materiality.
- Owners assigned per class (support, treasury, engineering, finance).
03
Operational signals
- Queue depth growing faster than close rate.
- Repeat classes tied to same SKU or rail.
- High rate of generic/other resolution codes.
04
Decision points
- Auto-resolve eligibility per class.
- When to escalate to finance close blocker.
- Merge versus split related payment_ids.
05
Escalation paths
- Class owner → operations lead when SLA breached internally.
- Engineering → provider when provider plane data missing.
06
Failure modes
- Closing exceptions without payment_id.
- Support overriding lifecycle without exception record.
07
Recovery patterns
- Reopen incorrectly closed items with audit note.
- Run taxonomy training for repeat mistake patterns.
- Instrument matchers to reduce false positives.
- Retries are normal. Webhook delivery is at-least-once. Design consumers to tolerate duplicates and out-of-order arrivals where possible.
- Asynchronous by design. Payers, chains, and your servers operate on different clocks. UI and finance should not assume synchronous finality.
- Eventual consistency. API reads, webhooks, and portal views may briefly diverge during transitions. Reconciliation jobs exist to converge truth.
Walkthroughs: /operations