Summary
An escalation policy offers a comprehensive view of who receives notifications and through which channels along the escalation path. A single escalation policy can be associated with multiple shifts. But you can also create a unique escalation policy tailored for a specific shift. In addition, an escalation policy enables users to define conditions based on multiple ticket standard and custom fields to tailor escalations as per unique circumstances.
Step 1
Select the second tab – Escalation Policies – on the on-call schedule page and click on Create escalation policy.
Step 2
Give the escalation policy a name. Choose the shifts to apply this escalation policy to.
Step 3
Define the condition that should trigger this escalation policy. In this example, escalation will be triggered if the incident priority is Urgent. You can choose additional conditions to fine tune the reason for escalation.
Step 4
Design the escalation path by:
- Specifying the agents who must be notified
- How soon after the incident is assigned to the agent group should they be notified
- What channels should they be notified on
- How soon should they be renotified in case the incident remains unacknowledged or unresolved
In the example given below, if the incident priority is Urgent, primary on-call agents are to be notified immediately (at 0 minutes) via phone call, email, & SMS. If the incident remains unacknowledged or unresolved for the next 5 minutes, the primary on-call agents will be renotified over phone call, email, SMS, and WhatsApp.
If on-call agents specified in the first level of escalation fail to acknowledge the incident, the notifications are escalated to level 2. In the above example, level 2 escalation requires primary and well as secondary on-call agents to be notified. Similarly, an incident can be escalated to up to five levels if it remains unacknowledged or unresolved.
By default, the Escalation Path features a single level mapped to the primary on-call roster. However, you can customize this setup as per your unique requirements. Some examples include:
Adding primary, secondary, and tertiary agents to level 1 while adding subject matter experts to level 2
Adding one or more subject matter experts (who are not agents) to the same level as the primary on call
Adding primary and secondary agents to level 1, tertiary on-call agents to level 2, and subject matter experts to level 3
Retaining just 2 levels or adding up to five levels of escalation
Each level can accommodate up to 10 agents and/or subject matter experts, and there are 5 levels available.
Step 5
Once you’ve designed the escalation path, specify the number of times the path could be repeated in case an incident remains unacknowledged.
Step 6
If you want, you can also notify up to 10 stakeholders – both agents & requesters – about the progress of an incident through a notification channel of your choice. While stakeholders can’t take action on an incident, this feature enables them to stay updated.
Step 7
Remember to Save the escalation policy before you exit the page.
Dynamic re-evaluation of escalation paths
Escalation policies (EPs) are also dynamically re-evaluated whenever changes are made to ticket fields that can be chosen conditions in dropdown for match conditions for escalations paths, including custom fields. This ensures that on-call notifications are triggered according to the most relevant escalation policy, reflecting the current state of the ticket.
Eg: Agent group has an on-call schedule with an escalation policy EP1 which is based on Impact = Low. EP1 is configured to send e-mails. The on-call schedule also has another escalation policy EP2 which is based on Impact = High and is configured to call the on-call agents.
When this agent group gets assigned to a ticket with Impact = Low, e-mails will get triggered as in the past. But if impact is updated to High (via workflow, manually, etc.) before any agent acknowledges the e-mail notifications, EP2 will match and phone calls will be triggered.
This functionality supports a wider range of incident management scenarios, ensuring that notifications remain relevant throughout the ticket lifecycle. It also ensures that the right escalation path is followed as ticket properties evolve. Plus, this reduces missed notifications due to outdated escalation path matches.
Note: 1. In case no escalation path is triggered when an incident is assigned to a group with an on-call schedule, the system will default to round-robin. 2. The order of esclation policies matters! For an incident, if there is an active shift with 2 matching escalation polciies, then the policy on top will be executed. 3. Download VCF files to identify calls from Freshservice.
