Escalations: The Ticket to Successful Problem Resolution

Kristin Robertson, KR Consulting, Inc.

April, 2003 

Have you ever been to a hospital Emergency Room?  Parents know that sick or injured children may require a visit to the local ER.  I have intimate knowledge of this: Once, my son had a severe allergic reaction.  I rushed him to the ER and ran in frantically yelling, “My son can’t breathe!”  Perhaps because of my panic, I can remember in vivid detail the process that quickly unfolded: We immediately saw the Triage Nurse who confirmed my son’s critical condition.  She whisked us into an examination room where a steady parade of medical professionals quickly appeared - as if by magic - to diagnose the problem and then administer the proper medications to help my asthmatic child.  What appeared at the time to be magic was really a rational, step-by-step triage and escalation process that the hospital professionals knew precisely how to execute.

As Support Center professionals, we must take a lesson from the Emergency Room.

A well-conceived and well-executed problem escalation process is as essential to the Support Center’s effectiveness as it is in the Emergency Room.  Fortunately, we don’t often deal with life-or-death situations.  However, a network outage or a bug that brings down a mission-critical application is a very serious and costly event for a company.  We need to be ready with an escalation plan that involves a parade of IT professionals, if needed, to solve the problem quickly and efficiently.

In this article, problem escalation refers to the process of involving 2^nd and 3^rd level IT or Product Development experts in solving a customer’s problem.  Escalation can sometimes connote the transfer of an angry customer to a supervisor or manager for further handling, but in this article we will use the term escalation to mean escalating a problem issue to a technician with more expertise.

How to begin?

We agree that our escalation procedures should be well-conceived and well-executed.  Where do we start?

Escalations start with a Service Level Agreement (SLA) that defines the severity rules used in prioritizing incoming support requests, plus the response and resolution times promised according to severity.  In the Emergency Room, it’s OK to let someone with a bad cold wait longer for medical attention than a patient who can’t breathe and is in need of immediate attention.  Likewise at the Support Center, it’s also necessary to prioritize support requests according to the impact on the business.  In order to maximize use of your IT resources and keep your customers productive, problems that affect only one worker must be prioritized lower than, say, a network outage that impacts a large number of employees.

You might use a severity matrix similar to this:

Many Support Centers also keep a VIP (Very Important Person) caller list, usually composed of executives or very important customers, whose problems are automatically prioritized higher than normal.  This is in recognition of the monetary impact created when these people are not productive. 

It is the Support Center’s responsibility to set the severity level of the service request, and it is not a negotiable issue with a customer.  However, if you provide support to external customers, you might want to allow the customer to set a priority level in addition to the by-the-book severity level.  In this way, a Severity Three (normal) problem can be tempered with a customer-set Priority One rating, perhaps because the customer is unable to run a report that they need to meet a deadline.  The Support Center can take the customer-set priority rating into account as they work the ticket.

Severity One (critical) requests are usually escalated immediately to a third level group after the Support Center gathers a thorough problem description.  For non-critical issues, the frontline Analyst first attempts to resolve the issue.  If the frontline is not able to solve the problem, the ticket is escalated in real time to a second level analyst within the Support Center. 

Second Level Support

Level Two support is provided by senior analysts within the Support Center.  To be fully effective, the senior analysts must be available for questions from the frontline on a real-time basis.  In larger Support Centers, seniors actually staff an internal ACD queue or are available via instant messaging (IM) to immediately help out the support analysts on the phones.  In small centers, they can be available by IM or in a more informal manner. 

There are three ways that a senior analyst can help the frontline:

If the frontline analysts are providing web chat support, the same procedure is used.  However, email support doesn’t demand such real-time assistance, so less formal ways of obtaining assistance can be used.  (Please note, however, that customers now expect a quick turn-around to their email inquiries.  Therefore, many companies are embracing a 4-hour response time goal to all email requests.)

This Senior Analyst either works the problem, or recognizes that it must be escalated to third level.

Now we start having fun!

Third Level Support

If second level support in the Support Center is not able to solve a problem, the issue is escalated to third level support groups, which are usually other IT or Product Development departments in the company.  The challenge here is that the issue is now out of the Support Center’s hands, even though they retain final ownership of the problem.  The timely resolution of issues escalated to third level requires teamwork and accountability across organizational lines. 

A best practice in Support Center management is to retain ownership of all tickets even after they have been escalated to other groups in the company.  The reason for this practice goes back to customer behaviour.  Who did the customer first talk to about this problem?  The Support Center.  Who will receive a call from the customer if they need a status on their problem?  Again, the Support Center.  Assuming “cradle-to-grave” ownership of all escalated issues doesn’t mean that the Support Center must be the only ones to communicate with the customer.  It is usually best if the third level analyst contacts the customer directly.  But it does mean that the Support Center management oversees the resolution process and reports resolution times plus SLA compliance to upper management.  It also means that the Support Center contacts the customer, either via automated email or by phone call, when the escalated issue is closed.  This not only creates a warm and fuzzy feeling for the customer, but also ensures that issues are resolved to the customer’s satisfaction and – importantly – adds to the credibility of the Support Center.

The Support Center runs, from their call tracking system, both aging reports and Service Level Agreement compliance reports.  Aging reports summarize, for each third level escalation group, how many tickets are open and for how long they’ve been open.  SLA compliance reports display each escalated problem, its severity, the elapsed time before 3^rd level response, the elapsed time before resolution, and if that resolution was in compliance with SLA guidelines.

Word of warning: Don’t even bother to run these reports if there is no one in the company who will enforce SLA compliance.  You must find an executive (the CIO, the VP of Technology or the VP of Development) who will make all third level escalation groups accountable to their SLA commitments.  Ideally, the reports that you generate are reviewed on a weekly basis so that the backlog of open tickets can be managed continually.  Open ticket reviews are usually conducted at the weekly staff meeting of the afore-mentioned executive, in which all participating groups are represented.  I’ve heard this meeting called the “Rank and Spank” meeting, in the sense that reviewing the aging report is the ranking and using public scrutiny on those groups that aren’t closing tickets according to SLA guidelines represents the spanking.  Perhaps you want to name your meeting something less negative, but the message is the same.

The best escalation plans identify a Problem Coordinator who gathers a team of IT or Product Development staff, as needed, to resolve an issue.  The Problem Coordinator is assigned according to the nature of the problem.  Often that person has the authority to pull their colleagues off other projects in order to resolve a critical issue. 

Following-up and Closure

After an escalated support request is resolved, it is up to the Support Center to follow-up with the customer to ensure their satisfaction.  As mentioned before, this puts the Support Center in the driver’s seat, encourages customers to call again, and gives the customer the assurance that the Support Center is on top of things.  The follow-up need not always be a phone call; sometimes a friendly email will do just fine.

Most Support Centers accomplish this step by creating a “resolved but not closed” status in their call tracking system.  This is the status code that the third level analyst enters when the issue is resolved.  The system then routes the ticket back to the Support Center, preferably to the analyst who originally took the call, for follow-up.  If you really don’t have the staffing to do follow-up calls, you can configure your call tracking system to automatically send an email at this point, but why pass on an opportunity to build customer loyalty?  Most centers have periods of time during the week when call volumes are low and can schedule out-bound calls.  Tickets are closed after the Support Center has successfully made contact with the customers and ensured their satisfaction.

The hospital Emergency Room provides many lessons for the Support Center.  It is our job as support professionals to create and manage efficient escalation procedures for complex issues that are not resolved at first level.  Our success in this endeavour enhances our image in the eyes of our customers and saves our company money. 

Kristin Robertson, President of KR Consulting, Inc., is a consultant to the Help Desk and Technical Support profession.  She helps companies increase the efficiency of their support center, save money, and increase their customer loyalty.  As both a consultant and trainer, she has worked with companies such as 7-Eleven, Southwest Airlines, Hewlett Packard, Prodigy Communications and CompUSA.  Kristin can be reached at 817-577-7030, or krisrob@krconsulting.com.  Her website, www.krconsulting.com, contains many free resources and articles for support professionals.