Escalation Policy Worksheet
Use this before you configure anything in a tool, and again when you review whether an existing escalation path still matches the service's response objective.
Placeholders
Everything in [square brackets] is a decision your team has to make. Replace all of them before you circulate the document.
"Someone else will pick it up" is not an escalation policy. This worksheet turns it into steps you can read, time you can add up, and a stop condition you can test.
What this worksheet covers
The policy header — what it applies to, when it starts, when it stops, and its maximum duration — then a step table covering target, parallel or sequential delivery, wait time, channel expectation and condition, followed by seven validation questions.
The question most policies fail
Does the worst-case time match the service objective? Add up every wait in the table. If a full pass takes longer than the response objective you have published, the policy and the objective disagree, and the policy is what will actually happen.
If you would rather work through it interactively and get a diagram, the Escalation Policy Builder produces the same artifact with the timing already summed.
Related
Template
Escalation Policy Worksheet
- Policy name: [name]
- Applies to: [services/teams]
- Default urgency: [urgency]
- Starts when: [trigger]
- Stops when: [acknowledged/resolved/manual]
- Maximum duration: [duration]
Steps
| Step | Target | Parallel or sequential | Wait | Channel expectation | Condition |
|---|---|---|---|---|---|
| 1 | [target] | [mode] | [duration] | [channels] | [condition] |
| 2 | [target] | [mode] | [duration] | [channels] | [condition] |
| 3 | [target] | [mode] | [duration] | [channels] | [condition] |
Validation questions
- Is every target active and reachable?
- Is the fallback independent of the primary?
- Does the worst-case time match the service objective?
- Is the stop condition explicit?
- Is after-hours behavior defined?
- Has the full path been tested?
- Is the policy owner named?