Defining Escalation

As more companies are exploring and implementing Intelligent Swarming, it has become apparent that the word “escalation” is one we’re using all the time, but often we’re using it to mean different things in different parts of the organization. Context is as important as content, and in the case of escalation, it’s worth getting some clarity and consistency on both.  

Escalation: to increase in extent, volume, number, amount, intensity, or scope

Merriam-Webster Dictionary

Merriam-Webster defines escalation as “to increase in extent, volume, number, amount, intensity, or scope.” In our organizations, we use “escalation” to mean a wide range of actions or activities, including asking for technical help on a case, passing off an angry customer, and/or requesting attention for an important account. 

With such a broad definition, it is not surprising that we find every company, department, team, and sometimes even individual using the word differently. This creates subtle, siloed confusion for the company and customers.   Mike Jasperson, Vice President at PTC, has years of experience working with customers in heightened states of engagement.  Mike has a simple way of setting context around the word escalation:

“‘Escalation’ is not about an internal process to move work from one person to another, it is about customer expectations.  Customers often look for vendors to change how they are engaging because an expectation is not being met.  Escalation should be a word describing a process used by a vendor to help manage risk and expectations with their customers.”

To this end, Mike talks about three types of escalations from a customer’s point of view:

  1. Issue Escalation:  I have a single-topic issue and my expectations on how this one issue is being handled does not meet my expectations.  I would like to speak with someone about actions I feel are needed to make progress.
  2. Incident Escalation:  I have a broader set of issues that are causing significant risk and your response is not meeting my expectations relative to my level of concern.  I need to engage with someone that can make decisions and engage the right resources to mitigate my risk.
  3. Account Escalation:  As a company, we are experiencing impacts and risks at the corporate level and we expect your senior leaders will engage to understand and react to our risks.

Whether adopting a three-level approach as Mike speaks to or something different, we need to look at escalation as a way to engage our customers in mitigating risks, not as an internal way to move work.

When we clearly define escalation as a systemic way to address customer expectations, we can focus on redefining activities a support agent might do when trying to solve a case.  Especially when we are implementing Intelligent Swarming, this distinction is key. 

In an Intelligent Swarming environment, we make every effort to get the right work to the right person to solve the issue on first engagement.  This has two dramatic results: first, we resolve issues faster, which opens up capacity internally. Second, we meet customer expectations upon first contact at a much higher rate, which improves the customer experience.  When we are not able to resolve issues on our own, we do not escalate work to a different person or team. No longer do we need to be passing work through multiple hands to solve an issue. We collaborate by raising our hand to ask for help, which has the added benefit of greatly reducing customer frustration. 

In this new environment, escalation is about exception handling for issues that do not fit a standard process. Changing our language so that “escalation” is about managing risk and expectations with our customers will serve our industry well.

3 thoughts on “Defining Escalation

  1. I like SO many things about this, Matt. Escalations are not about moving work from one tier to another, but about customer expectations- we do not escalate work to another team… I could go on and on.

    Also, now that we’ve all been working from home for a while isn’t it nice that a few family noises in the background is 100% acceptable?!

  2. I think taking the customer’s perspective, as you share from PTC, is a key missing ingredient in how we think about escalations.

    I’m also glad you pointed out the elephant in the room, too–escalations mean different things in different contexts, and unless we’re really clear about what we’re talking about, we’ll talk across each other. I don’t think we can replace the word, but adding a qualifying word as Mike Jasperson does seems like a great practice.

    Done right, Intelligent Swarming should reduce escalations in all its meanings!

  3. I agree with Matt and Mike that it is important to take the customer’s perspective into account when deciding what type of escalation is required although that is not something that we can expect the customer to categorise for us. Different users in the same customer will have different opinions about this! Just like priority codes – I had a user in one of my customers who always demanded Priority 1 for every issue he had, no matter how trivial! We had to listen to what he was saying, and apply his words to our agreed definitions of impact and urgency to decide the priority.

    However I think it is also important to ensure that definitions we use take into account and, where possible, are compatible with other methodologies. I think this is the reason why Matt says in his video that there are so many different views on what “escalation” means. And this applies to other terms as well, such as “issue” and “incident”.

    To explain my concern I will use ITIL as an example. I have great difficulty seeing how, when I am talking about KCS to my IT customers, all of whom are deeply aligned to ITIL terminology, they could accept these definitions used above.

    Matt’s description of an Issue Escalation is a one “topic” or a simple occurrence, but one that is not being fulfilled or resolved to the customer/user’s expectation. In ITIL “issue” is a generic term covering many defined types, like service requests (e.g. reset a password, install software, upgrade my PC, etc.), requests for a change to the service, incidents or problems. All these types of issue may be escalated, by either the user or the service provider, because their expectation are not meeting requirements.

    Matt’s description of an “Incident Escalation” is “a set of issues set of [related or repeat] issues that are causing significant risk and [our] response is not meeting [customer] expectations”. In ITIL, an “incident” is a “failure or reduction in the quality of a service”. Every time it happens is a separate incident. A “problem” in ITIL is defined as “the cause of one or more incidents”. A problem record is raised to investigate the incident/s to stop them recurring or, if that is not possible, to find a better way of resolving recurrences. This is in line with Matt’s description of Incident Escalation but is really what ITIL calls Functional Escalation not Hierarchic Escalation (see more later!). However Problem Management does not cover all types of issue, only Incidents.

    Some customer/user issues can be resolved at first point of contact and require no escalation. Others cannot be resolved at first point of contact and need to be referred to other people for diagnosis and/or resolution. ITIL calls this type of escalation “Functional Escalation”. It is not done because we are in trouble, it is simply the appropriate way of handling the issue, whatever type it may be, not just Incidents. (Libby, you might not agree with me that the latter is escalation at all, but many people do!)

    ITIL defines another type of escalation also applicable to issues of whatever type, called “Hierarchic Escalation”. This is, of course, about involving people further up the hierarchy. It is not about bumping responsibility up the management tree. Functional escalation may, probably will, also be required. It is more about raising the level of awareness, and may be up the service provider’s hierarchy, or the customer’s hierarchy but, if the latter, then I suggest both!

    To some extent I see Functional Escalation and Intelligent Swarming as different perspectives on the same thing, namely involving the best people to perform the action or provide assistance or advice. Hierarchic Escalation is more about communication, ensuring awareness. The higher up the hierarchy the less likely they are to be able to resolve the issue, although they may be able to make more functionally competent resources available!

    Hope this makes sense!

Leave a Reply

Your email address will not be published. Required fields are marked *