This chapter is from the book
This chapter is from the book
This chapter is from the book
Typical Incident Process
Most organizations have a formal process that technicians follow for any incident. An incident typically starts with a user reporting an issue and ends with a help desk technician closing it after the issue is resolved. However, there are many steps between the first and last step.
Steps in a Typical Incident Process
While not every organization uses the same process to manage incidents, there are many similarities between different processes. Organizations define the process internally and might combine or omit steps based on their needs. However, by reviewing a typical incident process, you are able to identify many of the common elements. As an introduction, Figure 1-4 shows the steps in a typical incident process and the following sections describe them in more depth.
)
FIGURE 1-4 Typical steps in an incident process.
Receiving Incidents
In the first step, the help desk receives the incident from a user reporting it. The method of reporting could be in person or via telephone, email, a chat page, or a web-based reporting tool.
When users report the incident via telephone, many organizations record the entire conversation. From a legal perspective, the organization normally has a requirement to notify users that the conversation is being recorded, and many automated help desk phone systems notify users prior to connecting them with technicians. Many electronic methods such as chat pages and web pages include a legal statement with a requirement for the user to check a box agreeing to the process.
One of the most important elements of success when receiving an incident is to respond appropriately and begin to establish rapport. Users often don’t have the right words to report the issue, so they might need to be coaxed into providing all the relevant information. Creating a friendly, helpful atmosphere will help the technician during the process.
Consider if you called your ISP for help and a technician responded with one of the following two phrases:
- “What do you want?”
- “Hello. My name is Sally. How can I can help you?”
Many people would likely respond with anger from the first greeting while the second greeting is warm and indicates a sincere desire to help. While this is obvious when you read it, it isn’t so obvious to all help desk technicians on the job. Organizations often provide help desk professionals with a script when starting a conversation, giving them the words to let the customer know they are there to help. For example, at least one ISP has their technicians answer the phone with these words: “Hello. My name is ____ and I can help you.” Help desk technicians will typically memorize the greeting after repeating it a few times so they don’t have to keep reading it.
Similarly, when communicating with users via email or chat pages, technicians often have pre-created scripts that they can cut and paste into the email or chat pages. These scripts typically include a greeting such as hello, an introduction including the technician’s name, and an offer to help. In the technician’s first response, they will typically include words expressing empathy along with confirmation that they can help. For example, they might say, “I’m sorry you’re having problems but I can help you resolve this.”
Validating Incidents
After the initial greeting, the customer reports the problem they are having. In this phase of the call, the technician attempts to verify it is a valid incident that the help desk should address, or if the call should be referred elsewhere.
Many organizations include an authentication procedure in this phase to ensure that the help desk is authorized to help the user. For example, an ISP help desk assists ISP customers so one of the first things that the technician does is to verify the customer’s identification number. Automated phone systems often verify the customer’s identification number prior to forwarding the call to a technician.
Organizations need to have clear guidelines in place on what support help desk technicians should provide. For example, if the help desk technicians are providing help to internal employees, they typically assist users with any type of problem with their computer or other IT resources.
In contrast, ISP help desk technicians only assist customers with IT problems related to the services provided by the ISP. For example, ISP technicians would assist customers having problems accessing the Internet through the ISP. However, users calling with a problem related to their printer would be told that the ISP does not provide that type of assistance.
Many organizations include a listing of items that the help desk will not support. For example, the following list could be used within an organization to ensure help desk personnel focus on supported incidents:
- The help desk does not provide support for employee’s personal computing devices. This includes home computers, laptops, tablets, and smartphones.
- The help desk does not provide support for any software products that were not approved by and purchased by our company.
Telling a customer “no” can be sensitive, and pre-defined scripts are useful to give technicians phrases that respectfully communicate the company policy to the customer. While technicians might think it’s funny that an ISP customer would call for help with their printer, it wouldn’t be appropriate to laugh. Instead, technicians would typically express empathy and then explain why they are unable to help with words such as this: “I’m sorry you’re having problems with your printer but we can only provide assistance related to the services we provide. I’d suggest you contact the printer manufacturer.”
Logging Incidents
Once technicians validate calls as actual incidents, they begin the process of logging them. A logged incident is also known as a ticket, or service ticket. Most organizations have applications to open, track, and close tickets through front end data entry screens, with all the data stored in a back-end database. These applications ensure proper data is entered and make it easy to track the incident through its lifetime.
Organizations using help desk software decide what information is required when logging the incident prior to deploying it. Some common customer data is name, email address, phone, and a customer ID if used. Next, a subject or category selection categorizes the incident. For example, technicians can categorize incidents as operating system problems, hardware problems, or network access problems.
A ticket also has a comment or remarks section where the technician can enter notes about the problem, and some ticket systems include an additional section to enter the original symptoms. It’s possible for symptoms to change while troubleshooting and clearly logging the original symptoms helps keep technicians on track. The technician’s ability to write clearly and concisely is extremely important in this step.
Some ticket systems allow the technicians to enter the data in any order. For example, Figure 1-5 shows an example web-based ticket system. Help desk technicians access this system with a web browser and are able to enter the information as the user is talking. In the figure, you can see that the technician is able to enter symptoms from the customer first, but can later enter the customer ID and other customer information. This allows the technician to listen to the customer and gather some information without forcing the user to answer a series of questions. This is especially useful if a customer has been waiting on the phone for a while and finally is able to talk to a technician. After the user explains the problem, the technician can say something like, “I understand, and we can help you with this. In case we get cut off, I want to make sure I have all your information. Can I ask you a couple of questions?” The technician then fills in the other necessary data such as the Customer ID.
)
FIGURE 1-5 Example of web-based ticket creating system.
In contrast, some systems force customers to enter an account number through the automated voice mail system, but the account number is just used to authenticate the user and isn’t used for further reference. After the customer waits 15 minutes or so to talk to a live person, the technician begins asking a series of questions such as account number, customer name, customer email, and so on. This often just frustrates the customer further.
When planning the process for a help desk, it’s important to think about the customer’s perspective. The immediate issue for the customer is the problem at hand. When the customer is forced to repeat customer data multiple times, it becomes very tedious and frustrating. For example, some help desk procedures force the customer to enter identifying data such as an account number when first calling an automated phone system. Then when a technician takes the call, the technician asks for this information again to verify the caller is a customer. Later, after the technician realizes the incident should be logged, the technician once again asks the customer for this information to enter it into a ticket. Customers can get so frustrated they want to reach through the computer and take out their frustration on the technician, as shown in Figure 1-6.
)
FIGURE 1-6 Ineffective logging systems can frustrate customers.
One of the most efficient methods of using a ticket system combined with an automated phone system is to ensure that they are integrated with one or more databases. The phone system prompts the caller to provide a customer number, and it validates the customer number against a customer database. The phone system only forwards calls to the help desk that are from valid customers. When the phone system forwards a call to the technician, it populates the ticket with the customer ID, along with the customer’s name, email, phone number, and so on. Looking at Figure 1-5, the technician would see the ticket with most of the information filled in and can then focus on the problem.
In some cases, the user has a simple question that the technician can easily answer in less than a minute. Should the technician create a ticket for this? It depends. Most ticket applications include analysis capabilities. Management can review them periodically to extract quantifiable data and measure the performance of the help desk. However, if technicians are not creating tickets consistently, this data is not reliable. Consider these two scenarios:
First, imagine a star technician that quickly resolves user issues without taking much time at all. Without clear guidance from management, this gifted technician might not log most of these incidents, thinking that they are trivial and not worth logging. In contrast, another technician without the same level of expertise might help customers with the same types of problems, but take much longer before he can resolve them. When management later analyzes the incident logs, it might look as if the gifted technician is doing significantly less work than other technicians are, even though he is solving more customer problems.
In the second scenario, imagine that a specific user has extremely limited IT knowledge and is calling the help desk almost daily asking for help. The problems are easy to solve so technicians do not log them, but it still takes time for technicians to assist this user creating an overall help desk backlog. Help desk management might ask senior leadership for a budget increase to hire a new help desk technician. However, if these logs are analyzed, it would indicate that the help desk has enough technicians, but the technicians are not clearing many tickets.
Organizations should make it clear to technicians when to create a ticket and when tickets shouldn’t be created. Junior technicians don’t always understand the big picture of an organization, or even how budgets work, and without clear guidance, technicians will log tickets inconsistently. It does take time to log all problems, and technicians might think they are helping the organization by helping more customers without logging the incidents.
There aren’t any rules that work for all organizations on what incidents to log. However, the key is that management needs to make a decision and communicate it to the technicians. If technicians don’t have guidelines on what incidents to log, each technician will make their own decisions and these decisions might not match the goals of the organization.
Screening Incidents
Once the technician begins logging the incident, the screening phase begins. During this phase, the technician asks a series of questions about the problem. Both effective questioning techniques and active listening techniques go a long way in this step (Chapter 2 goes into these techniques in much more depth).
When screening the incident, the goal is to get the actual symptoms. Based on the symptoms, technicians determine if this is a problem they should be helping the customer with, or if they need to escalate it. Here are some examples of complaints from a customer and responses by the help desk technician:
- Customer: “The Internet is down.”
- Technician: “What are you trying to do that isn’t working?”
- Customer: “Why doesn’t my printer work?”
- Technician: “I’m not sure. What is happening when you try to print?”
- Customer: “My computer keeps crashing.”
- Technician: “That doesn’t sound good. Can you explain what it does when it crashes?”
- Customer: “My account is locked and I can’t log on. Can you help?”
- Technician: “I’m sorry you’re having problems. I cannot unlock it, but I can connect you with technicians that have permissions to do so.”
In the first three issues, the problem is very likely one that the help desk technician can help the customer resolve so the technician begin asking more questions about the problem. However, in the fourth example, the technician doesn’t have adequate privileges to resolve the problem and must escalate it.
Prioritizing Incidents
Some incidents are extremely important while others are not. Most ticketing systems include the ability to assign a priority to an incident and organizations clearly define the different priorities. There isn’t a universal definition that applies to all organizations, but many use simple low, medium, and high priorities.
High-priority incidents indicate problems or issues that are affecting a significant number of users and are affecting one or more mission-critical functions or services. Mission-critical functions or services are those that are integral to the organization performing their core business. For example, a company that primarily sells products online through a website would consider all the functions and services of the website as mission critical. This could be the website server, access to back-end database or any other services needed by the website applications, and Internet connectivity. Similarly, an ISP might consider an outage affecting hundreds of users as a high-priority issue.
Medium priority incidents prevent a single user from performing mission-critical functions or services. If a user’s computer fails but the user is still able to perform tasks on another computer, it wouldn’t meet this definition. Another possibility of a medium-priority issue is if an issue degrades the performance and reliability of several IT mission-critical IT services. For example, if a router failed on a network, the network might remain operational using alternate paths, but the increased traffic on these alternate paths could significantly slow down the network.
Low-priority incidents indicate issues affecting a single user or issues that are degrading the performance and reliability of non-mission-critical IT services. For example, it would be a low priority if a single user was unable to access email on one computer but can access email on another computer.
Assigning Incidents
Typically, the help desk technician that receives the call will follow it through to completion. However, if the technician doesn’t have the expertise or permissions to resolve the problem, it might be necessary to assign the incident to another technician. In some cases, the technicians refer the incident to another help desk technician who has specialized experience and knowledge for the problem. In other cases, the technician might need to escalate the issue to a higher-level tier.
Escalating Incidents
If technicians cannot resolve a problem, they escalate it by sending it to a higher-level tier. There are two primary reasons why help desk technicians escalate a problem:
- The technician runs out of ideas to resolve the problem. For example, the problem might be beyond the technician’s expertise level. By escalating the problem to a higher tier, a more experienced technician is able to resolve the problem for the user.
- The technician doesn’t have adequate privileges to resolve the problem. For example, the technician might realize that an account needs to be created on a server but the technician doesn’t have the required privileges to create the account. Technicians at higher tier levels have progressively more privileges.
Help desk supervisors will typically monitor escalated incidents closely. If technicians are constantly escalating simple problems due to a lack of privileges, the supervisor can facilitate an increase in privileges for the technicians. This allows the problem to be resolved quicker, ensures customers are satisfied quicker, and requires less work for the upper tier levels. Additionally, if a single technician is escalating significantly more incidents than other technicians are, this technician might need additional training.
Resolving Incidents
Once the organization addresses the incident completely, it is considered resolved. In most situations, this indicates that the customer’s question or problem has been answered or solved. For example, a customer reports a problem accessing the Internet, and the help desk is able to assist the customer to restore their access.
In some cases, the customer might not be satisfied but the incident is still resolved. For example, a customer might want to perform a specific task with an application and request assistance to achieve his goal. After investigating, the help desk might discover that that the application doesn’t include the desired feature and communicates this to the customer. The customer might not be happy with the answer, but help desk personnel have done all they can to resolve the problem.
Closing Incidents
Technicians close the incident once the incident is resolved. This typically involves logging the resolution into the incident software and selecting the option to close it. Closed incidents are usually still accessible to help desk personnel. This way if a customer calls back after a short time, they can easily view the history and reopen it if necessary.
Help desk personnel are often provided with a script to close the ticket. For example, they might ask “Is there anything else I can help you with today?.” The goal is to ensure that customers have what they need and will not be calling back in a short time.
Tracking Incidents
While most organizations recognize the need for help desks, they also want to ensure that the costs are justified. One of the primary methods of justifying costs is through metrics. A metric is a method of measuring something and it provides quantifiable data used to gauge the effectiveness of a process.
Some of the common metrics used to measure the effectiveness of a help desk are:
- New incidents. This identifies the workload imposed on the help desk team.
- Resolved incidents. Ideally, the help desk team should be closing about the same number of incidents as they receive. If not, it indicates there aren’t enough qualified technicians to handle the workload or the technicians are not able to focus on help desk workload.
Backlog. The backlog is simply the number of new incidents minus the resolved incidents. If the number of resolved incidents is consistently less than the number of new incidents, the backlog will continue to grow. Figure 1-7 shows a graph displaying new incidents, resolved incidents, and the backlog over a few weeks. Management personnel reviewing this graph can easily see that that backlog is steadily climbing and address the problem before it gets too serious.
FIGURE 1-7 Example graph of new incidents, resolved incidents, and backlog.
- Reply time. The reply time might indicate how long it takes a customer to get a response from an email or Internet-based help desk system, or how long it takes them to talk to a live help desk technician, depending on how the help desk is set up. Ideally, users will receive a quick response to let them know the incident has been received and will be worked on. If this is too long, customers will quickly become dissatisfied.
- First resolution time. The time between the initial incident report and its resolution is the resolution time. A challenge with this metric is that some help desk supervisors encourage technicians to resolve problems as quickly as possible so that they can help other customers. However, if the technician rushes to a resolution, the customer might not be fully satisfied and might call back.
- Final resolution time. Some tickets are closed prematurely, indicating a quick first resolution, but the customer soon calls back because the problem hasn’t been resolved. Technicians reopen the original ticket and keep it open until it is truly resolved. Gaps between the first resolution time and the final resolution time indicate problems that management needs to investigate. For example, if one technician has a high number of tickets that other technicians are reopening when the customer calls back, it indicates the technician is not successfully helping the customers before closing the ticket the first time. This is adding additional workload onto the help desk.
- Customer satisfaction. The ultimate goal of the help desk is to meet the needs of the customers and you can determine this by having customers fill out short surveys and report their satisfaction with the service.
- Technician performance. Performance of individual technicians can be measured based on how many tickets they resolve, how many tickets they resolved but were reopened due to the customer calling back, and satisfaction ratings from the customers. Technicians with lower metrics might need additional training while technicians with superior metrics might be ready to move up to tier 2 or a help desk supervisor or management position.
)
Taking Ownership of Incidents
Successful help desk specialists (and employees at any job) can often enjoy great success by implementing a simple philosophy of problem ownership. The most successful technicians are diligent, tenacious, and focus on resolving all the details of an incident with a dedication to excellence. From a broader perspective, these same traits contribute to the success of people at any job.
In contrast, some technicians see incidents as problems and focus on transferring them rather than resolving. If customers are lucky, they will eventually be transferred to a technician that will take ownership of the incident and follow it through to resolution. If not, the customer will likely experience a high level of frustration and associate the bad experience with the company name.
However, this requires the organization to allow technicians to stick with a problem. Some large organizations have policies in place where technicians stick with the customer even as they transfer customers to a different area of the organization. In contrast, some large organizations have policies in place where technicians simply transfer the customer, forget about the issue, and move on to the next problem.
Here are two examples.
In one situation, I called Verizon asking for assistance with my iPad and its Internet access through the Verizon cellular network. The technician wasn’t able to resolve the problem but recognized that sales personnel could resolve it. However, instead of just transferring the call, she contacted the sales personnel, explained the problem to them, and then brought them onto the line to help me. The sales personnel couldn’t completely resolve the problem but instead needed to transfer me to another area. Ultimately, I was on the line for over an hour and was transferred three different times, but this technician was with me every step of the way. She expressed empathy at the difficulty we were having at resolving the problem and even though the problem wasn’t completely resolved, I still ended the call with the feeling that she did everything she could.
At another time, I called a different company related to an issue I was having. I was transferred four times and each time I had to identify myself and explain the problem again. By the time I reached the fourth technician, I was extremely frustrated at the company’s customer service. The technician spoke with an accent and after I told him I was having problems understanding him, he suggested I call back.
While I certainly applaud the technician in the first scenario due to her customer service capabilities, I can’t completely fault the technicians in the second scenario. The company procedures were apparently reinforcing the technician actions of referring problems rather than solving them.
If a company is able to implement a simple philosophy of encouraging technicians to take ownership of problems, it can significantly increase customer satisfaction. It also places the onus of resolving the problem on the first technician that receives it. Management is better able to identify technicians that do not have the skills to resolve problems but instead transfer them whenever possible.