# Escalation decision matrix

Worked example companion. Fictional scenario; no measured results.

The escalation is useful when the next action has been accepted by a person.

## How to use this sheet

Replace the example rules with your own. Keep each acceptance decision linked to its owner and evidence. Use the blank CSV to record your actual process; the example CSV contains teaching material.

| Situation | Action | Completion evidence |
| --- | --- | --- |
| Eligible ticket; no escalation | Create owned escalation | Record ID and next-action owner |
| Known shared incident | Link to incident | Reviewed incident ID |
| Owner has acknowledged | Stop repeat acceptance alerts | Acknowledgment timestamp |
| Owner unavailable | Use defined backup | New owner and decision reason |
| Ticket resolved during evaluation | Cancel pending escalation | Current status and cancel reason |
| Notification failed | Retry delivery only | Existing escalation ID retained |

## Workflow

1. **Evaluate policy** (Help desk): Read priority, clock and current ticket state.
2. **Find existing incident** (Support lead): Reuse an escalation or reviewed incident link.
3. **Assign next action** (On-call policy): Select the duty owner and deadline.
4. **Acknowledge or advance** (Duty owner): Record acceptance or invoke the backup path.

Exception: Recheck resolved tickets before writing. Missing roster coverage goes to the support lead. Notification retries reuse the same escalation and issue.

## Measurement

For a defined severity cohort, measure escalation-to-acknowledgment time, unowned escalations and duplicate engineering issues. Record clock policy and coverage hours. Keep resolution time separate from acknowledgment.

## Limitations

- Actual service commitments and coverage windows must be defined by the support organization.
- A notification cannot substitute for staffed response capacity.

Source page: https://www.opsautomators.com/work/support-escalation-ownership
Prepared September 7, 2026.