There will probably be some calls that you just cannot solve, and they must be handed off to someone else. This is called escalation. Escalation is nothing to be ashamed about; it’s a fact of life. Don’t let help desk personnel (or yourself) hang on to a problem because they are embarrassed to admit they are stumped. This goes for all levels. Even if the expert cannot solve the problem and it must be passed on to the software or hardware vendor, that will happen.

Although the help desk cannot guarantee that the problem will be solved within a certain time, you can institute policies to ensure that it doesn’t just sit on someone’s desk. By forcing escalation within a certain time, you make sure that calls are being worked on efficiently. Granted, there may be calls where the help desk member can "taste" the answer and wants to continue working on it. That’s okay and I encourage you to let the help desk staff hang on "just a little while longer." You just don’t want them hanging on too long.

The key is that the escalation procedures are designed to move the call efficiently. Notnecessarily quickly, because you want a resolution, not just numbers showing how fast you are. When the call is escalated, the user needs to be informed. This helps to assure the user that the problem is being worked on and that the help desk is not just passing the problem around. The escalation times as well as the procedures need to be part of your help desk guidelines. Everyone needs to stick to them. If possible, the help desk software should be made to do some of this automatically. Among other things you need to include are:

• Who can decide to escalate a call? If one person has it too long, can the expert simply "take" it from the other person? Can a manager force an escalation?
• When do you escalate? After how long and under what circumstances? Certain types of problems may automatically get escalated to the expert or even the vendor.
• How are the problems escalated and to whom? What are the procedures?
• Who has the ultimate "ownership" of the call? The first person? The last?
• Who resolves problems with the escalation process? What if you forget to address one aspect and you run into problems? Who decides how to handle it?

There are actually two different kinds of escalation. The most commonly recognized kind is a technical escalation that is passed to someone who is in a better position (technically) to solve the problem. The other kind is an administrative escalation where there is something other than a technical issue that needs to be resolved. For example, if there is some disagreement in terms of whether something is supported or not, the help desk analyst may not be in a position to make the necessary determination. A nontechnical issue is normally escalated through management channels.

If you’re working in an environment where support is paid for, the calls you often break downnontechnical escalation issues into service-related and sales-related issues. Service-related issues are those where the customer did not get the level of support that was either promised or expected. The sales-related issue is where the customer either wishes to upgrade the product or service war wishes to return the existing product.

In some companies, the support representative is responsible for both technical and sales-related issues. Therefore, sales issues are not "escalated." In other companies, where these functions are separate, the call is handed off from one organization to another and can be considered to have been escalated. Obviously, if support is not paid for, there are no sales-related calls.

Being able to identify what kind of escalation is necessary is an important aspect of dealing with the call in general. As with classifying the type of problem, if you cannot properly classify the type of escalation, the call gets sent to the wrong person, which wastes everybody’s time.

Keeping track of the escalations is just as important as keeping track of the problems themselves. Experience has shown me that there are a few basic causes for administrative escalations. You should therefore address these causes to ensure they do not reoccur. For example, one of the most common administrative escalations is caused by improper expectations on the part of users. That is, users expect the help desk to provide more support than what has been promised. It is quite common to have users expect you to "hold their hands." Telling the user just what the solution is is not sufficient. Instead, the help desk is expected to walk them through each step of the solution until it has been fully implemented.

If a large number of users complain that the help desk is not providing them this level of support, and it was not promised in the SLA, there are two solutions. First, it may be necessary to modify the SLA so that "hand-holding" is part of the service that is provided. However, management must be made aware of the extra burden that this will cause. The second solution is to provide additional training for the users so that hand-holding is not necessary.

If you’re using a FL/BL model for your basic work flow, it may still be important to monitor at least the number of calls that are passed from the front line to the back line. If you are using the TH model, you need to decide what happens when the call is escalated. For technical issues, escalations should be less frequent with a TH model. You are expected to hold on to the call until it is resolved.

However, there will be cases where you cannot solve the problem, and it needs to be handed to someone else. The question is whether the original analyst maintains ownership of the problem. Personally, I feel that ownership should follow the call, even after escalation. If an analyst cannot solve the problem, and it needs to be escalated to someone else, the new analyst should then take over the ownership of the call. However, if the call is escalated outside of the help desk, such as to different department, ownership should be maintained by the person who has direct to the user. (This, of course, depends on your organization.)Keep in mind that one of the major benefits of the TH model is that theanalyst learns more by working on the complicated issues. If the analyst never learns what the solution is, he or she will probably need to escalate a similar call the next time. Therefore, it is extremely important that the resolution be reported back to the original analyst.

Due to their very nature, escalations often require more communication skills than are needed for normalcalls, especially if analysts are dealing with nontechnical issues. With technical issues, you are likely to be spending more time with the customer and more time asking about the user’s system and getting them to provide information.

With this in mind, you might find it useful to create a specific function that is responsible formanaging the escalations. This should be someone at the management level, as they have the authority to make decisions. Granted, your help desk staff could be given that authority, but they should spend their time dealing with the technical issues and following your established procedures.

Here you need to think of economies of scale. That is, the more escalations you have, the more you need a dedicated function. If you find that escalation issues are taking time away from other duties, it is time to seriously begin thinking about a dedicated escalation manager. If you don’t, analysts will either neglect their other jobs or the escalation will be handled improperly. Obviously, if you discover that there are more escalations than one person can handle, you might even consider an escalation team.

Regardless of whether or not you have a dedicated manager, you need to consider that one of the major causes of nontechnical escalations that are the results of complaints is personality differences between the user and the analyst. The escalations manager will therefore need to be part psychologist in order to resolve these personality conflicts. Therefore, communication skills are even more and the requirement with the escalations manager as they are with the regular analyst.

Although the dedicated escalation function is a better positioned to look at the root causes objectively, an analysis can still be done by members of the help desk staff. I think it is an important part of the analysis to begin working on it as soon as possible, even before the problem is been resolved. In doing so, you cannot only help prevent repeat occurrences, but you can also help bring this call to a speedy conclusion.

For example, let’s take a call that results in escalations because the user is not satisfied with the local service. If you determine early that the user is demanding more support than is provided for by the SLA, the answer to the user may be fairly straightforward. On the other hand, I know some managers who immediately declare at the beginning that the help desk analyst is not doing their job. There is no investigation, just blame. This wastes time, especially considering that next time the analysts will probably give that user more support than they should, just to avoid getting "yelled at." Added to this is the other users who get less service than they should, because analysts are working with the "screamers."

The analysis of the escalation should include everyone involved within the help deskorganization. In some cases, it may also be useful to include the user in determining the root cause. However, you must keep in mind that it is highly likely that the user will not be asobjective as the people on the help desk, particularly if the escalation was caused by the user’s misunderstanding of what support will be provided. On the other hand, this misunderstanding may be the catalyst for a reevaluation of the SLA.

During this analysis, there are several things that are vital to keep track of:

• the cause of the escalation
• the steps taken to resolve the problem
• problems you encounter during the resolution
• what things helped in reaching the resolution
• what might be done in the future to prevent a similar escalation

If the solution can be implemented within the help desk, it should be implemented as soon aspossible. If it requires the participation or approval of someone outside the help desk (such as changes to the SLA), the escalation manager (or help desk manager) should begin working on the changes as soon as possible.

One problem that I repeatedly see during this analysis is finger pointing. Consider the escalation due to a misunderstanding of the SLA. You may think it reasonable to put the "blame" on the user for expecting more support then they are entitled to. However, is it not the "fault" of the help desk for providing an SLA that was open to such misunderstandings? On the other hand, is it then not the "fault" of the users for not specifying more clearly what kind of support they expect? This does nothing other than pass the blame back and forth across the table. The cause of the problem was a misunderstanding of the SLA, which needs to be addressed without putting the blame on anyone.

Regardless of what type of escalation it is (sales, service, technical), the call needs to be owned by the help desk, as they are the ones with the direct contact to the user. Especially in cases where the call is addressed by someone in another department, it is important that the single point of contact be maintained. For example, if the user needs a new computer and makes a request of the help desk, who in turn puts in a request to the company’s purchasing department, the user should not be expected to contact purchasing to determine the status of the order. Instead, the help desk should monitor the request and keep the user informed of the status. (Obviously, this may not be feasible within your organization.)

When I was in support, I knew several engineers who would quickly rattle off the steps to solve the problem. "Do this. Do that. Do this other thing. If you have more problems feel free to call back." At first, they seemed to have a great record. In some cases, they had more than twice the calls per hour as other people. Then the department started monitoring the number of calls that were reopened, that is, the calls where the support analyst didn’t solve the problem the first time. Considering those calls, these people had a much worse average. This is because the customer did not understand the answer and often was not given the chance to ask questions. As a result, when the customer started to work on the problem and discovered that the information they received from support was insufficient, they were on the phone again. This wasted time and cost money for everyone involved.