Unito’s Guide to Getting Your Ticket Escalation Workflow Right
Not every ticket gets resolved on the first try. Difficult issues, technical questions, and situations out of your control can all lead to a ticket needing to be escalated to a leader or a completely different team. That’s why having a robust, documented ticket escalation workflow is so important. Without this workflow, every ticket has the potential to balloon into a massive, costly issue.
So how do you get this workflow under control? How do you measure its effectiveness?
Here’s Unito’s guide to this essential workflow.
What is ticket escalation?
Ticket escalation is a process through which tickets that need additional expertise or authority are routed to the team or manager that can handle them. For some tickets, that escalation might just come after someone requests a manager. For others, the perspective of an expert is needed to reveal the solution.
Whether you’re managing a customer support team or an IT department, ticket escalation is an essential part of your work.
Why ticket escalation is such an important process
You can’t handle support tickets without an escalation process. Frontline agents can’t handle every ticket that comes in; that approach isn’t scalable and rarely even possible. Likewise, without an established ticket escalation process, you won’t have clear guidelines on when tickets should be escalated, where they should go, and how the recipient should respond.
By clearly establishing, streamlining, and optimizing a ticket escalation process, everyone gets clarity on exactly what needs to happen with a ticket, no matter how complex it is.
The 3 types of ticket escalation
Not every ticket escalation is the same, but most follow one of these three types.
Hierarchical escalation
A hierarchical escalation follows your org chart. With this kind of escalation, a frontline agent is looking for authority. They might need a manager to make a difficult decision, make an exception, or just give guidance on the right way to solve a ticket.
Functional escalation
Functional escalation is about skills and knowledge. In this type of escalation, a frontline agent might be looking for support from an engineer for a technical issue, a lawyer for a legal issue, or a software developer for a tenacious bug.
SLA (time-based) escalation
SLAs (service level agreements) are contractual terms that cover the level of service you’re expected to deliver. They might cover ticket escalation metrics like mean time to resolution (MTTR) or time to escalation. Tickets that are taking too long to resolve might be escalated for SLA reasons so an expert or manager can close them quickly.
A breakdown of the ticket escalation process
While each organization might have its own specific ticket escalation process, they usually follow these steps.
Initial assessment and handling
At this stage, frontline agents receive a ticket and perform an initial assessment. This involves identifying the core issue and looking for potential solutions. The agent might compare the ticket to known problems or trends across their department. No escalation is happening at this stage yet; frontline agents are doing the best they can to resolve the problem themselves.
Escalation trigger identification
As frontline agents start handling a ticket, they look for potential triggers that could lead to an escalation. In some cases, that’s as simple as a submitter requesting a manager. In others, it might involve an agent digging and finding a software problem that only an engineer is equipped to handle.
Routing
After a trigger for escalation is identified, the frontline agent escalates that ticket and sends it to the right place. This might be automated, with a ticketing system that sends escalations to the right place, or an agent might have to manually send a ticket to the right department.
Customer communication
Once a ticket is escalated, frontline agents communicate with the submitter to keep them in the loop. That might involve telling them who the ticket was escalated to or sharing an expected timeline for resolution.
Monitoring and resolution
Frontline agents typically keep an eye on escalated tickets, communicating updates to customers as they become relevant. In the meantime, whoever received the escalated ticket works on resolving it, letting frontline agents know as soon as the deed is done.
Follow-up and documentation
An escalated ticket’s journey doesn’t end when it’s closed. Often, the frontline agent responsible for initially escalating that ticket will be the one communicating with the submitter. They might be expected to sum up how the ticket was resolved and communicate that.
Additionally, escalated tickets are often documented in one way or another, contributing to a more streamlined escalation process and better data.
When should a ticket be escalated?
Frontline agents are typically responsible for identifying when a ticket needs to be escalated, but that identification depends on a pre-established process. Here are some common escalation triggers.
Authority is needed
Sometimes it’s as simple as the person submitting the ticket requesting a manager. In other situations, a ticket can only be resolved with a decision that someone with authority can make. These escalations are generally pretty quick to route and resolve, with the main obstacle being the backlog of whoever has the authority to close the ticket.
Expertise is required
In many industries, frontline agents need to route escalated tickets to specific experts. In software, for example, a frontline agent might need to escalate a ticket to a software developer to deal with a tenacious bug. An IT service desk might escalate a ticket to an engineer specializing in a specific system. Finally, a customer support agent in a consulting business might escalate a ticket to the legal department to review aspects of a contract.
The issue is too complex
Not all escalated issues neatly fit with pre-established triggers. Sometimes, a frontline agent will be left scratching their head after running into an issue they don’t have the skills or knowledge to resolve themselves. There might not be a predetermined process for escalating some of these complex tickets, meaning frontline agents sometimes need to rely exclusively on their judgment to escalate more complex tickets.
Trending issues
Some tickets can be tied directly to known issues, making them easy to escalate. As soon as a frontline agent can recognize the link between a ticket and one of these issues, they can escalate it to whoever’s responsible for investigating a solution and communicate that to the submitter.
Ticket escalation: Customer support vs. IT
Ticket escalation is an essential process in both customer support and IT, but there are some key differences in how it’s handled in each department.
Ticket escalation in customer support
In customer support, ticket escalation has one main goal: customer retention. When losing a customer (customer churn) can be so much more expensive than getting a new one, organizations pour a massive amount of resources into keeping existing customers. The volume of tickets in customer support can often be overwhelming, which makes having clear processes for escalation so much more important. Frontline agents are responsible for routing tickets to any number of departments, including experts in software or legal. This can often cause tickets to disappear into a black hole of sorts, creating an added administrative burden for frontline agents as they chase updates for customers.
Ticket escalation in IT
Ticket escalation is very different for IT departments and IT service agencies. IT tickets can cover a wide variety of tools, services, and issues, which makes it difficult to standardize tickets. Because tickets vary so much, frontline agents might have to spend a significant amount of their initial time getting to the core of an issue, confirming what troubleshooting steps the submitter has taken, and delaying the time to an escalation. Routing tickets after an escalation is often simpler than in customer support, since an initial escalation might only go to a single department, or an expert within that department. Triggers for escalation are often clearer than in customer support, meaning processes around this are easier to enforce. Similar standards apply in DevOps, as well.
Essential ticket escalation metrics
Your ticket escalation workflow involves several metrics you can measure to determine its effectiveness.
Mean time to resolution (MTTR)
Mean time to resolution (MTTR) measures the time from when a ticket is received to when it’s resolved, averaged out over all your tickets. This metric is typically a core element of SLAs (Service-Level-Agreements), and is generally used as an indicator of your workflow’s overall health.
Time to escalate
Time to escalate tracks the time between when a frontline agent first receives a ticket and when they escalate it. A short time-to-escalate shows that your escalation triggers and process are clear. A time-to-escalate of several hours (or even days) shows that your process has some issues.
Handoff delay time
Handoff delay time measures the period between when a frontline agent first escalates a ticket and when the person it’s escalated to actually takes it on. Many organizations don’t track this metric, but handoff delay time can reveal gaps in your ticket escalation process that need fixing.
Context loss
Context loss measures the essential information that gets lost when tickets get escalated. That doesn’t just make an escalated ticket potentially confusing when it’s received, it forces whoever’s handling it to double up on work as they investigate what’s missing. This metric is tracked as a percentage of all escalated tickets (i.e., a 10% context loss rate means 10 tickets in 100 have lost context).
Escalation bounceback rate
Escalation bounceback rate tracks the amount of tickets that are returned to frontline agents for extra information after being escalated. It’s expressed as a percentage (e.g. a 30% escalation bounceback rate). A good bounceback rate should be in the single digits. Once you hit 20% and over, you should reevaluate your process.
Priority mistranslation rate
Priority mistranslation rate reflects the percentage of tickets that don’t have their priority properly reflected as they move from system to system. This percentage should be low, at 5% or less, since a higher rate shows a technical program in the systems you use for ticket escalation.
Repeat escalation rate
A repeat escalation describes a ticket that’s been escalated multiple times, whether it’s by different agents or after an agent’s first escalation didn’t lead to a resolution. You should pay attention if this rate reaches 20% or more. You’re likely losing a significant amount of time to tickets being bounced back and forth between departments.
8 tips for a smoother ticket escalation process
Looking to improve your ticket escalation process? Here’s how.
Identify and define escalation criteria
Frontline agents shouldn’t have to guess whether a ticket needs to be escalated or not. Your ticket escalation process should have clear triggers and criteria for when a ticket should (and shouldn’t) be escalated.
Does asking for a manager automatically guarantee an escalation? Or does your frontline agent have more authority in adjudicating these requests? Are there specific issues or questions that always need to be escalated?
Clearly defining and documenting these criteria—and keeping that documentation up to date—is essential.
Support frontline agents
Your ticket escalation process should account for your frontline agents solving as many tickets as they can without escalating them. One of the best ways to streamline ticket escalation is to give frontline agents the support, training, and resources they need to close a variety of tickets. Fewer escalations means your process doesn’t get bogged up, other teams don’t get overwhelmed, and every ticket is handled more efficiently.
Standardize tickets
Standardizing tickets allows everyone from frontline agents to the departments receiving escalated tickets to know exactly what to expect. When every ticket follows the same format, frontline agents know exactly what to add before escalating them, and other departments are less likely to send these tickets back. This indirectly helps improve all ticket escalation metrics you track.
Automate ticket routing
The more decisions a person has to make along your ticket escalation process, the slower and more cumbersome it is. That’s why you need to look for opportunities to automate parts of this process, including ticket routing. Most software platforms used for ticket escalation have built-in automations that allow tickets to get automatically sent to the right department when specific fields are changed. Look into using these to save time on every escalation. Otherwise, you’ll lose time, money, and other resources to manually escalating every ticket.
Monitor metrics and find ways to optimize
The ticket escalation metrics listed above aren’t just nice-to-haves; they can completely transform your process. When you start measuring them, you’ll get alarm bells ringing when certain elements of your process aren’t working properly. Then, you can make these specific metrics a focus of any improvements you want to make, spot-fixing issues in your process.
Explore AI tools
AI tools, from AI chatbots in customer success to AI copilots when resolving escalated tickets, can accelerate and streamline your ticket escalation process. Exploring these tools means comparing them against one another, identifying pain points you need to resolve, and running pilot projects to test them out. AI agents are especially powerful tools for ticket escalation, since they can move your workflow forward independently.
Prioritize context
Escalated tickets live and die depending on the context frontline agents provide. That doesn’t mean that whoever’s receiving that ticket needs to know absolutely everything that happened, but frontline agents should be able to share all the context that’s needed. The best way to do that? Clearly document context that’s essential and context that can be left out.
Consider software integration
The right software integration brings together your support ticket system and the platforms other departments actually handle escalated tickets in. It automatically creates work items in each system to match tickets as they’re escalated, meaning both frontline agents and the agents handling escalated tickets can work from the platform they know best without losing any context. Cross-tool visibility is essential for ticket escalation, whether that’s in customer support or IT.
That’s the piece that’s most important, and it should guide you towards picking the right integration. Not losing context. And there’s only one integration solution suited to this essential workflow.
Unito is a two-way sync solution for platforms like Jira, ServiceNow, Smartsheet, Asana, and more. It automatically creates work items to match original tickets as you escalate them, updating fields in both as you work. Need to ask a frontline agent for more context? Just add a comment in your tool and it’s replicated in the other. Adding context from a customer call? Add it to a custom field and it’s carried over automatically.
With its no-code interface, deep integrations, and fully customizable flows, Unito has everything you need to fully integrate your ticket escalation workflow—without the months-long deployment of other platforms.
Want to see what Unito can do?
Meet with Unito product experts who'll show the impact of the right integration on your ticket escalation workflow.