\nThere will probably be some calls that you just cannot solve, and they must be handed off to someone\nelse. This is called escalation<\/i>. Escalation is nothing to be ashamed about; it\u2019s a fact of\nlife. Don\u2019t let help desk personnel (or yourself) hang on to a problem because they are embarrassed\nto admit they are stumped. This goes for all levels. Even if the expert cannot solve the problem and\nit must be passed on to the software or hardware vendor, that will <\/i>happen.<\/p>
Although\nthe help desk cannot guarantee that the problem will be solved within a certain time, you can\ninstitute policies to ensure that it doesn\u2019t just sit on someone\u2019s desk. By forcing escalation\nwithin a certain time, you make sure that calls are being worked on efficiently. Granted, there may\nbe calls where the help desk member can "taste" the answer and wants to continue working\non it. That\u2019s okay and I encourage you to let the help desk staff hang on "just a little while\nlonger." You just don\u2019t want them hanging on too long.<\/p>
The key is that the escalation\nprocedures are designed to move the call efficiently. Notnecessarily quickly, because you want a\nresolution, not just numbers showing how fast you are. When the call is escalated, the user needs to\nbe informed. This helps to assure the user that the problem is being worked on and that the help\ndesk is not just passing the problem around. The escalation times as well as the procedures need to\nbe part of your help desk guidelines. Everyone needs to stick to them. If possible, the help desk\nsoftware should be made to do some of this automatically. Among other things you need to include\nare:<\/p>
There are actually two different kinds of escalation. The\nmost commonly recognized kind is a technical escalation that is passed to someone who is in a better\nposition (technically) to solve the problem. The other kind is an administrative escalation where\nthere is something other than a technical issue that needs to be resolved. For example, if there is\nsome disagreement in terms of whether something is supported or not, the help desk analyst may not\nbe in a position to make the necessary determination. A nontechnical issue is normally escalated\nthrough management channels.<\/p>
If you\u2019re working in an environment where support is paid for,\nthe calls you often break downnontechnical escalation issues into service-related and sales-related\nissues. Service-related issues are those where the customer did not get the level of support that\nwas either promised or expected. The sales-related issue is where the customer either wishes to\nupgrade the product or service war wishes to return the existing product.<\/p>
In some companies,\nthe support representative is responsible for both technical and sales-related issues. Therefore,\nsales issues are not "escalated." In other companies, where these functions are separate,\nthe call is handed off from one organization to another and can be considered to have been\nescalated. Obviously, if support is not paid for, there are no sales-related calls. <\/p>
Being\nable to identify what kind of escalation is necessary is an important aspect of dealing with the\ncall in general. As with classifying the type of problem, if you cannot properly classify the type\nof escalation, the call gets sent to the wrong person, which wastes everybody\u2019s time.<\/p>
\nKeeping track of the escalations is just as important as keeping track of the problems themselves.\nExperience has shown me that there are a few basic causes for administrative escalations. You should\ntherefore address these causes to ensure they do not reoccur. For example, one of the most common\nadministrative escalations is caused by improper expectations on the part of users. That is, users\nexpect the help desk to provide more support than what has been promised. It is quite common to have\nusers expect you to "hold their hands." Telling the user just what the solution is is not\nsufficient. Instead, the help desk is expected to walk them through each step of the solution until\nit has been fully implemented. <\/p>
If a large number of users complain that the help desk is\nnot providing them this level of support, and it was not promised in the SLA, there are two\nsolutions. First, it may be necessary to modify the SLA so that "hand-holding" is part of\nthe service that is provided. However, management must be made aware of the extra burden that this\nwill cause. The second solution is to provide additional training for the users so that hand-holding\nis not necessary. <\/p>
If you\u2019re using a FL\/BL model for your basic work flow, it may still be\nimportant to monitor at least the number of calls that are passed from the front line to the back\nline. If you are using the TH model, you need to decide what happens when the call is escalated. For\ntechnical issues, escalations should be less frequent with a TH model. You are expected to hold on\nto the call until it is resolved.<\/p>
However, there will be cases where you cannot solve the\nproblem, and it needs to be handed to someone else. The question is whether the original analyst\nmaintains ownership of the problem. Personally, I feel that ownership should follow the call, even\nafter escalation. If an analyst cannot solve the problem, and it needs to be escalated to someone\nelse, the new analyst should then take over the ownership of the call. However, if the call is\nescalated outside of the help desk, such as to different department, ownership should be maintained\nby the person who has direct to the user. (This, of course, depends on your organization.)Keep in\nmind that one of the major benefits of the TH model is that theanalyst learns more by working on the\ncomplicated issues. If the analyst never learns what the solution is, he or she will probably need\nto escalate a similar call the next time. Therefore, it is extremely important that the resolution\nbe reported back to the original analyst.<\/p>
Due to their very nature, escalations often\nrequire more communication skills than are needed for normalcalls, especially if analysts are\ndealing with nontechnical issues. With technical issues, you are likely to be spending more time\nwith the customer and more time asking about the user\u2019s system and getting them to provide\ninformation. <\/p>
With this in mind, you might find it useful to create a specific function that\nis responsible formanaging <\/i>the escalations. This should be someone at the management level,\nas they have the authority to make decisions. Granted, your help desk staff could be given that\nauthority, but they should spend their time dealing with the technical issues and following your\nestablished procedures. <\/p>
Here you need to think of economies of scale. That is, the more\nescalations you have, the more you need a dedicated function. If you find that escalation issues are\ntaking time away from other duties, it is time to seriously begin thinking about a dedicated\nescalation manager. If you don\u2019t, analysts will either neglect their other jobs or the escalation\nwill be handled improperly. Obviously, if you discover that there are more escalations than one\nperson can handle, you might even consider an escalation team.<\/p>
Regardless of whether or not\nyou have a dedicated manager, you need to consider that one of the major causes of nontechnical\nescalations that are the results of complaints is personality differences between the user and the\nanalyst. The escalations manager will therefore need to be part psychologist in order to resolve\nthese personality conflicts. Therefore, communication skills are even more and the requirement with\nthe escalations manager as they are with the regular analyst.<\/p>
Although the dedicated\nescalation function is a better positioned to look at the root causes objectively, an analysis can\nstill be done by members of the help desk staff. I think it is an important part of the analysis to\nbegin working on it as soon as possible, even before the problem is been resolved. In doing so, you\ncannot only help prevent repeat occurrences, but you can also help bring this call to a speedy\nconclusion.<\/p>
For example, let\u2019s take a call that results in escalations because the user is\nnot satisfied with the local service. If you determine early that the user is demanding more support\nthan is provided for by the SLA, the answer to the user may be fairly straightforward. On the other\nhand, I know some managers who immediately declare at the beginning that the help desk analyst is\nnot doing their job. There is no investigation, just blame. This wastes time, especially considering\nthat next time the analysts will probably give that user more support than they should, just to\navoid getting "yelled at." Added to this is the other users who get less service than\nthey should, because analysts are working with the "screamers."<\/p>
The analysis of\nthe escalation should include everyone involved within the help deskorganization. In some cases, it\nmay also be useful to include the user in determining the root cause. However, you must keep in mind\nthat it is highly likely that the user will not be asobjective as the people on the help desk,\nparticularly if the escalation was caused by the user\u2019s misunderstanding of what support will be\nprovided. On the other hand, this misunderstanding may be the catalyst for a reevaluation of the\nSLA.<\/p>
During this analysis, there are several things that are vital to keep track\nof:<\/p>
If the solution can be implemented within the help desk, it should be implemented as soon\naspossible. If it requires the participation or approval of someone outside the help desk (such as\nchanges to the SLA), the escalation manager (or help desk manager) should begin working on the\nchanges as soon as possible.<\/p>
One problem that I repeatedly see during this analysis is\nfinger pointing. Consider the escalation due to a misunderstanding of the SLA. You may think it\nreasonable to put the "blame" on the user for expecting more support then they are\nentitled to. However, is it not the "fault" of the help desk for providing an SLA that was\nopen to such misunderstandings? On the other hand, is it then not the "fault" of the users\nfor not specifying more clearly what kind of support they expect? This does nothing other than pass\nthe blame back and forth across the table. The cause of the problem was a misunderstanding of the\nSLA, which needs to be addressed without putting the blame on anyone.<\/p>
Regardless of what\ntype of escalation it is (sales, service, technical), the call needs to be owned by the help desk,\nas they are the ones with the direct contact to the user. Especially in cases where the call is\naddressed by someone in another department, it is important that the single point of contact be\nmaintained. For example, if the user needs a new computer and makes a request of the help desk, who\nin turn puts in a request to the company\u2019s purchasing department, the user should not be expected to\ncontact purchasing to determine the status of the order. Instead, the help desk should monitor the\nrequest and keep the user informed of the status. (Obviously, this may not be feasible within your\norganization.)<\/p>
When I was in support, I knew several engineers who would quickly rattle off\nthe steps to solve the problem. "Do this. Do that. Do this other thing. If you have more\nproblems feel free to call back." At first, they seemed to have a great record. In some cases,\nthey had more than twice the calls per hour as other people. Then the department started monitoring\nthe number of calls that were reopened, that is, the calls where the support analyst didn\u2019t solve\nthe problem the first time. Considering those calls, these people had a much worse average. This is\nbecause the customer did not understand the answer and often was not given the chance to ask\nquestions. As a result, when the customer started to work on the problem and discovered that the\ninformation they received from support was insufficient, they were on the phone again. This wasted\ntime and cost money for everyone involved.<\/p>\n","protected":false},"excerpt":{"rendered":"
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\u2019s a fact of life. Don\u2019t let help desk … Continue reading