<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=299788&amp;fmt=gif">
Skip to content

itsm

Escalation is a process. When it comes to proper IT Service Management (ITSM) escalation, your team's success at handling high-priority incidents and requests will depend on the structure of that underlying process. No software tool on the market will be able to define that process for you, as escalation is subjective and should be based on a team, its goals, and its method of management. Luckily, tools like Jira Service Desk can help structure, document, and track that process to ensure incidents are resolved quickly and properly, leading to the discovery of root causes to those incidents.

Every team is different, but some general methods of escalation can be utilized as a part of your unique process. Functional Escalation and Hierarchical Escalation are the two most prominent methods and can be thought of as horizontal and vertical escalation, respectively.

Functional escalation is described as horizontal in nature because it is about shifting the issue to the proper team, but at the same level of priority. This could mean moving it to a software development team for change issues or incidents requiring technical fixes, or simply shifting it to another customer-facing help desk like Human Resources because they have the team and process to handle that type of request. 

Hierarchical escalation, on the other hand, is vertical in nature and represents a more traditional vision for escalation, where the priority of the request is high, and the request needs a more senior or experienced level of employee to handle it. We see this type of escalation most often when the first tier of support isn't able to resolve the request, or the visibility of the request or its associated incident needs to be resolved at a higher level in the organization because of its high priority.

 

flow-of-hierarchical-and-functional-escalation

 

Priority is typically defined by a combination of urgency impact, or rather how quickly something needs to be resolved and how much it will affect the subject of the incident. Within Jira Service Desk, just like all of Jira, there is an inherent field for hierarchical and customizable Priority. This field is often leveraged to define where in the escalation process a request lands. If your organization is on the smaller side, and you have a single JSD project, then escalation is typically handled in two ways.

Primarily we like to recommend utilizing JSD Queues, which is the Service Desk project version of Jira Filters, allowing users to query all the requests in the JSD project in regards to any of the associated criteria (fields) on the requests. As you may imagine, we can easily use the default priority field to query our requests and automatically push them into tiered queues, as seen below. 

 

image2020-5-22_11-41-49

 

The other option is to have these tiers of escalation as workflow statuses that your request handlers (agents) will transition the request into when it needs to be escalated. I don't like to recommend this option simply because this means the request can't be in any other status while being escalated, which undermines the structure of most processes. However, workflows do have more robust automation capabilities that some team's more complex processes require, so this is always an option for those teams.

As for larger organizations that are handling millions of requests and have several help desk projects, we often utilize entirely separate projects as tiers of escalation that have dedicated configurations and teams. Jira Service Desk is set up quite well for this since requests originating from one help desk project can easily be transferred to another project, or linked to an issue in another project (like a software project). This moving or linking process can also be automated as part of your unique escalation process, helping to mitigate that tedious and often overwhelming manual work involved in service request management. In that regard, JSD and Jira Cloud have out-of-the-box automation engines that make it easy and intuitive to create automation rules for those common manual steps of your process.

 

image2020-5-22_11-59-42

 

Ultimately, you also want your ITSM escalation process to properly track these incidents throughout their escalation lifecycle, and notify the right people at the right times during this cycle. To assist with that, JSD offers very flexible Service Level Agreement functionality. Using the Jira Query Language or JQL, we associate SLA timers to specific groups of issues. This is the same querying process that queues use to pull specific types of requests utilizing the criteria associate with them. Therefore, when you define your SLA goals, you can grab requests based on their priority and attach the timers to them. Start, pause, and stop conditions are also defined for SLA goals (with calendars auto-pausing when agents are off work). These timers are great visual indicators on the request view for your agents to stay on track, as well as the foundation for all the custom reporting in JSD to see overall trends of your escalated incidents.

 

image2020-5-22_12-2-6

image2020-5-24_13-57-4

If your team is looking for a new way of tackling escalation for IT Service Management, look no further than Jira Service Desk, as it has the flexibility for you to define an escalation process perfect for your teams and organization. With the cross-project connections, dynamic queues, custom SLA goals, and built-in, easy to use automation, Atlassian's Jira Service Desk will give you all the tools needed to take your escalation to the next level!

 

Atlassian Solution Partner

See More From These Topics