Home > Articles

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

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

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

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:

  1. 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.
  2. 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

    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.

Pearson IT Certification Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Pearson IT Certification and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Pearson IT Certification products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by Adobe Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.pearsonitcertification.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020