What is IT incident management?

What is an IT incident?

An IT incident is any disruption to an organization's IT services that affects anything from a single user or the entire business . In short, an incident is anything that interrupts business continuity.

What is IT incident management?

Incident management is the process of managing IT service disruptions and restoring services within agreed service level agreements (SLAs).

The scope of incident management starts with an end user reporting an issue and ends with a service desk team member resolving that issue.

The Stages in Incident Management

With proper incident management in place, collecting information about incidents is streamlined and less chaotic without having emails fly back and forth for the purpose. Service desk teams can publish forms in user self-service portal to ensure that all relevant information is collected right at the time of ticket creation.

The next stage in incident management is incident categorization and prioritization. This not only helps sort incoming tickets but also ensures that the tickets are routed to the technicians, most qualified to work on the issue. Incident categorization also helps the service desk system apply the most appropriate SLAs to incidents and communicate those priorities to end users. Once an incident is categorized and prioritized, technicians can diagnose the incident and provide the end user with a resolution.

Incident management process when enabled with the relevant automations allows service desk teams to keep an eye on SLA compliance, and sends notifications to technicians when they are approaching an SLA violation; technicians also have the option to escalate SLA violations by configuring automated escalations , as applicable to the incident. After diagnosing the issue, the technician offers the end user a resolution, which the end user can validate. This multistep process ensures that any IT issue affecting business continuity is resolved as soon as possible.

How to classify IT incidents

Incidents in an IT environment can be categorized in several different ways. Some factors that influence incident categorization include the urgency of the incident and the severity of its impact on users or the business in general. Classifying and categorizing IT incidents helps identify and route incidents to the right technician, saving time and effort. For example, incidents can be classified as major or minor incidents based on their impact on the business and their urgency. Typically major incidents are the ones that affect business-critical services, thus affecting the entire organization, and need immediate resolutions. Minor incidents usually impact a single user or a department, and might have a documented resolution in place already.

What happens when you don't have IT incident management in place?

Incident management covers every aspect of an incident across its life cycle. It speeds up the resolution process and makes ticket management transparent. Without incident management, handling tickets can be a hassle. Some of the key problems that can arise include:

• Lack of transparency on ticket status and expected timelines for end users.
• No proper record of past incidents.
• Inability to document solutions for repeat or familiar issues.
• Higher risk of business outages, particularly with major incidents.
• Stretched resolution times
• Lack of reporting abilities.
• Decreased customer satisfaction

Who uses IT incident management?

Incident management practices are widely used by the IT service desk teams. Service desks are usually the single point of contact for end users to report issues to IT management teams.

The incident management process can be summarized as follows:

• Step 1 : Incident logging.
• Step 2 : Incident categorization.
• Step 3 : Incident prioritization.
• Step 4 : Incident assignment.
• Step 5 : Task creation and management.
• Step 6 : SLA management and escalation.
• Step 7 : Incident resolution.
• Step 8 : Incident closure.

These processes may be simple or complex based on the type of incident; they also may include several workflows and tasks in addition to the basic process described above.

Incident logging

An incident can be logged through phone calls, emails, SMS, web forms published on the self-service portal or via live chat messages.

Incident categorization

Incidents can be categorized and sub-categorized based on the area of IT or business that the incident causes a disruption in like network, hardware etc.

Incident prioritization

The priority of an incident can be determined as a function of its impact and urgency using a priority matrix. The impact of an incident denotes the degree of damage the issue will cause to the user or business. The urgency of an incident indicates the time within which the incident should be resolved. Based on the priority, incidents can be categorized as:

• Critical
• High
• Medium
• Low

Incident routing and assignment

Once the incident is categorized and prioritized, it gets automatically routed to a technician with the relevant expertise.

Creating and managing tasks

Based on the complexity of the incident, it can broken down into sub-activities or tasks. Tasks are typically created when an incident resolution requires the contribution of multiple technicians from various departments.

SLA management and escalation

While the incident is being processed, the technician needs to ensure the SLA isn't breached. An SLA is the acceptable time within which an incident needs response (response SLA) or resolution (resolution SLA). SLAs can be assigned to incidents based on their parameters like category, requester, impact, urgency etc. In cases where an SLA is about to be breached or has already been breached, the incident can be escalated functionally or hierarcially to ensure that it is resolved at the earliest.

Incident resolution

An incident is considered resolved when the technician has come up with a temporary workaround or a permanent solution for the issue.

Incident closure

An incident can be closed once the issue is resolved and the user acknowledges the resolution and is satisfied with it.

Post-incident review

After an incident has been closed, it's good practice to document all the takeaways from that incident. This helps better prepare teams for future incidents and creates a more efficient incident management process. The post-incident review process can be broken down into various aspects, as shown below, and is particularly useful for major incidents.

Internal evaluation

Incident identification

• Who detected the incident and how?
• How soon was the incident detected after it occurred?
• Could the incident have been identified earlier?
• Could any tools or technologies have aided in the prompt or pre-emptive detection of the incident?

Information flow and communication:

• How quickly were the stakeholders informed about the incident?
• What channel was used for relaying notifications?
• Were all the relevant stakeholders promptly updated with the latest information?
• How easy was it to communicate with the end user(s) to gather information and keep them informed on the status of the ticket?

Structure

• How was the incident response team initially structured?
• Was this structure adhered to throughout the incident management life cycle? If not, why? What changes had to be made to the structure?
• Can the incident handling team be organized in a better way? If so, how?

Resource utilization

• What resources were employed to handle the incident?
• Were those resources used to their optimal capacity?
• How quickly were resources mobilized to handle the incident?
• Could resource utilization be improved in the future?

Process

• How closely was the defined incident management process followed?
• Were there any deviations in the incident management workflow and process?
• Were the incident SLAs honored? If not, which SLAs were breached? Why?
• Was there adequate monitoring of the process being followed for handling the incident?
• Could the process be improved to make it more efficient? If yes, how?

Reporting

• Were reports generated to analyze how the incident was handled?
• What parameters were included in the reports?
• Which parts of the incident life cycle were analyzed?
• Is there any room for improvement? If so, how can it be achieved?

External evaluation - End User surveys

Apart from the above factors, some end-user facing factors should also be evaluated. For this purpose, a post-closure survey is conducted to collect feedback from the end users affected by the incident. This survey should be used to gain insight in some key areas, like:

• How easy or difficult was it for the end user to report an incident?
• Was the first response from the IT team swift and prompt?
• Was the incident resolved in a timely manner?
• How satisfied is the end user with the resolution?

Although each organization can have their own custom roles and responsibilities, below are some of the most common IT incident management roles.

End user / user / requester

This is the stakeholder who usually experiences a disruption in service and raises an incident ticket to initiate the process of incident management.

Tier 1 service desk

This is the first point of contact for the requesters when they want to raise a request or incident ticket. The Tier 1 service desk usually consists of technicians who have a working knowledge of the most common issues that might occur in an IT environment, including password resets and Wi-Fi problems.

Tier 2 service desk

This service desk is made up of technicians with advanced knowledge of incident management. They usually receive more complex requests from end users; they also receive requests in the form of escalations from Tier 1.

Tier 3 (and above) service desk

This level is usually comprised of specialist technicians who have advanced knowledge of particular domains in the IT infrastructure. For example, technicians for hardware maintenance and server support specialize in very specific fields.

Incident manager

This stakeholder plays a key role in the process of incident management by monitoring how effective the process is, recommending improvements, and ensuring the process is followed, among other responsibilities.

Process owner

This stakeholder owns the process followed for managing incidents. They also analyze, modify, and improve the process to ensure it best serves the interest of the organization.

Each role has unique responsibilities, as shown below.

End user / user / requester:

• Contact the service desk to raise a new incident request.
• Follow up on an existing request.
• Clearly communicate all the required information to technicians.
• Acknowledge the restoration of service and completion of the ticket.
• Respond to follow-up surveys after ticket resolution completing the feedback loop.

Tier 1 help desk:

• Log all incoming incident requests with appropriate parameters like category, urgency, andpriority.
• Assign tickets to technicians.
• Analyze and resolve an incident to restore service.
• Escalate unresolved incidents to the Tier 2 service desk.
• Gather all required information from the requesters and send them regular updates on the status of their request.
• Act as a point of contact for requesters, and, if needed, coordinate between the Tier 2 support desk and requesters.
• Verify the resolution with the end user and collect feedback.

Tier 2&3 service desk:

• Carry out incident diagnosis.
• Document the steps followed to resolve the incident and submit knowledge base articles.
• Identify when an incident is a problem and convert the incident ticket to a problem ticket.
• If the incident is resolved, confirm the resolution with the end user.
• If the incident is unresolved, escalate it to the Tier 3 service desk.
• If unresolved, escalate the incident to the IT problem management team for identifying the underlying issueor external vendors as applicable.
• Provide subject matter expertise.

Incident manager:

• Serve as the point of contact for all major incidents.
• Plan and facilitate all the activities involved in the incident management process.
• Ensure that the correct process is followed for all tickets and correct any deviations.
• Coordinate and communicate with the process owner.
• Ensure that SLAs are complied with.
• Identify the incidents that need to be reviewed and carry out the review.

Process owner:

• Take accountability for the overall process of incident management.
• Define key performance indicators (KPIs) and align them with critical success factors (CSFs).
• Review KPIs and ensure that they meet business goals and CSFs.
• Design, document, review, and improve processes.
• Establish continuous service improvement (CSI) wherein the procedures, policies, roles, technology, and other aspects of the incident management process are reviewed and improved upon.
• Stay informed about industry best practices and incorporate them in to the incident management process.

• Offer multiple modes for ticket creation including through an email, phone call, or a self-service portal.
• Publish business-facing, custom IT incident forms for effective information gathering.
• Automatically categorize and prioritize IT incidents based on ticket criteria.
• Associate SLAs with IT incidents based on ticket parameters like priority.
• If all technicians, are of the same skill levels, auto-assign tickets to technicians based on algorithms like load balancing and round robin.
• Associate IT asset data, IT problems, and IT changes with IT incident tickets.
• Ensure that incidents are closed only after providing a proper resolution by confirming with end user and applying the appropriate  closure codes.
• Configure a custom end-user communication process for every step in an IT incident life cycle
• Create, and maintain a knowledge base with appropriate solutions
• Provide role-based access to end users and technicians based on the complexity of the solutions.
• Handle major incidents by creating unique workflows.