Efficient ITSM comprises four main processes: service request management, change management, problem management, and incident management. IT companies should deal with all of them in order to provide end-to-end customer service. The comprehensive approach to ITIL guidance helps reduce overall project costs and significantly improves the customer experience. In this article, we will develop the topic of incident management. Why is it so important and how does it align with your business goals? 

Incident management defined by ITIL (Information Technology Infrastructure Library) is a set of actions performed by IT or DevOps teams to respond to service interruptions or negative unplanned events. The goal of the management process is to get the service back to operating as smoothly as possible. An incident is resolved if the impacted service resumes functioning in its operational state. Usually, we distinguish between major and minor incidents based on their severity. They can range from the whole service crashing to intermittent errors that concern only a small number of users. 

The ITIL incident management process consists of multiple stages. First, a user, a system, or a team member finds and reports an interruption. Then, we should long and describe an incident at a service desk along with all related links to tasks. In the next step, the agents review the incident and properly categorize it. It helps the team during post-incident activities and reporting. After the classification, we prioritize the incident, based on its urgency or impact on the service. When we already have a priority set up, the team can move on to diagnosing and finding possible solutions. During this stage, the support agents take care of the communication with incident reporters. Finally, the service team resolves the incident. After verifying whether the fix has been successful, the team can close the incident. It’s a good practice to fully document the resolution stages for future reference. 

A service can’t be fully functional when plenty of incidents happen. Especially if the same issues repeat or if they are severe. Let’s take for example security-related problems such as data leaks. In this case, mishandled incident management impedes patching these leaks. This may result in financial penalties for the organization or even worse consequences.

Incidents also negatively influence customer satisfaction and that means a lot in a competitive IT market. Clients won’t stay if there are constant interruptions. They are more likely to choose other solutions or another company to work with rather than dealing with issues and contacting the support team every day. Even if the agents do their best, the time spent on additional communication increases the project’s budget. Not to mention the frustration resulting from the inability to perform because of the inoperative service. The other significant aspect is economizing employees’ resources. Ineffective incident management leads to going back and forth to fix the same mistakes. Instead, the teams should take care of new or just more demanding problems. The consequences are visible not only in delays when it comes to project deadlines. Poor incident management can also reflect in employees’ professional burnout. 

ITIL distinguishes between incident management and problem management. At a first glance, an incident and a problem seem to be very similar as they both cause service malfunction. What are the differences between them? ITIL defines a problem as a cause or potential cause of one or more incidents whereas an incident is a single unplanned event that leads to a service disruption. An incident can be traced back to a wider problem. 

Problems and incidents are connected to each other. Both need to be properly managed by the team. The ITIL guidelines advise traditional IT teams to treat incidents and problems separately. According to them, problem management should be focused on preventing incidents and minimizing their impact. Incident management, on the other hand, concentrates on fixing existing incidents quickly, possibly in real time. The strong point of this approach is that the goals of both processes are clear and well prioritized. The transparent division helps to avoid the situation in which the whole IT team tries to get rid of minor incidents instead of looking for the root problem. The weaker side of ITIL’s approach is a possible knowledge gap between incident resolution and problem analysis. Any breakdown in communication can lead to a misunderstanding of the cause. 

Besides ITIL, there’s also a DevOps approach that treats problems and incidents as two inseparable halves. The supporters of the DevOps methodology point out that incidents often have more than one root cause. They believe that only collaboration leads to improvement. There’s no point in excluding any part of the team if a service is impacted by an incident or a problem. The key challenge of DevOps teams is making sure that problem management won’t get postponed endlessly in favor of incident management.

It’s impossible to predict all issues that may occur during the software development process. However, we can prepare the teams with some universal pieces of advice. Atlassian came up with the values that guide the teams on how they can approach incidents to identify, resolve, and finally learn from them. We believe there’s something in them for all of us.

If the team is able to spot a service interruption before the clients, it will save lots of time for the support team agents. What’s more, protecting users from incidents will surely get a company some trust points. This is why it’s a good idea to monitor service functionalities regularly. The smart way of doing it is to set up alerts that can automatically inform the team once anything goes wrong.

When customers let the team know that the service is down, the best we can do is focus on minimizing the impact and fixing it as soon as possible. Incidents will always be a part of software services. There’s no point in wasting time blaming a client or an employee. Customers will appreciate our work if we know how to make the interruptions go away. We can build users’ trust by letting them know about both scheduled and unplanned downtime. Making your clients and employees informed about what’s going on will surely pay off. 

A quick ad hoc reparation of an incident often is not enough. After the incident happens, the team should identify its root cause and implement changes that will fix it. Taking care of the broader problem will also prevent similar, related incidents from occurring. A more global approach can turn out to be prevention and an overall improvement of service at once. Remember that establishing a strong, logical incident management process is crucial to quickly reducing the impact and restoring services.

Gain the trust of your clients back by not letting the same incidents happen again. Always look for the bigger picture as it will protect you from repeating errors. The best idea is to create an incident management playbook. Plan your incident response strategy in advance. And we’re not only talking about technical issues. If there were communication problems during the improvements – draw your conclusions from this too. However trivial it sounds, use incidents to make your service better. 

The main goal of the system is to provide the teams with in-depth details about any errors or disruptions within the service. Proper incident management helps to identify the time, circumstances, and details of any particular interruption. The useful system should support collaboration inside and across the teams. Just as in the case of any other tool, it’s essential that the incident management one is intuitive, even for non-tech team members. It should be easy to learn and customizable. In order to provide all necessary information, a system for managing incidents needs to have functionalities that allow categorization, linking, and tracking of issues. The functional software helps reduce incident resolution time with, for example, notifications, a ticketing system, or additional integrations. Last but not least, it should offer processes for getting to the root of the problem after the incident lifecycle ends. 

ITSM processes have significantly developed over the last few years. The digital transformation of businesses forced the IT market to fulfill the expectations of more demanding customers. In order to do that, the companies look for the resources that will help to provide the best quality service. At some point, Atlassian’s Jira Service Desk needed to evolve into Jira Service Management to comprehensively cover the growing ITSM needs. 

Jira Service Management is a solution that meets all the requirements of an efficient incident management tool. An intuitive service desk allows customers and team members to notify about service issues. The alerts from clients, employees, and automated notifications are gathered in one place where they can be categorized and prioritized. Jira Service Management lets the Support team keep in touch with the clients during the process. It also informs everyone involved about the current issue status. Thanks to this, a company gains trust and can reduce the number of incoming tickets. The teams can automatically create post-incident reports to improve incident response practice in the future. In Jira Service Management, all related tasks are linked to each other so the employees are able to track them to completion and find the root cause easily. 

Jira Service Management provides a dedicated workflow called Incident Management workflow for Jira Service Management. It’s a good idea to start with it and then adapt the workflow to your business’s individual needs. Below we will present some tips that should help your team manage incidents in JSM. 

First, we recommend setting up Service Level Agreements, so it will be possible to track if the team is meeting the customer’s expectations. Jira Service Management has built-in SLAs where project admins can create specific goals. It can be done in the Project Settings, and then the SLA section. The goals should determine the types of requests we wish to track and the estimated time to resolve them. At this point, we can define the conditions and calendars that change when SLA measurements start, pause, or stop.

The next thing will help your team prioritize incidents. If a critical service error appears, it can be marked as major. Major issues are more visible than others and grouped under the JQL-powered Major incident queue. To mark an issue as a major, we need to turn on the major incident toggle in the Details section. 

Jira Service Management allows Slack integration with our service project. We already know that when it comes to incidents, the sooner we step in, the better. With Slack connection, we can create dedicated channels for all our incidents by clicking on the Create channel link. Then we can add incident responders to these channels, update incident priorities, and take incident actions. All this is to help the team act faster in the case of incidents.

The internal stakeholders are not direct responders to an incident. Nevertheless, they still need to be updated about the progress to take precautions and actions. With Jira Service Management, we can add people as stakeholders and update them with e-mail messages. We add stakeholders by selecting Manage next to the stakeholder’s field under issue details. To send an update, we select Update stakeholders from the Activity section of the issue view. 

Jira Service Management lets you easily check the source of incidents. Each issue view has a linked issues field with a list of connected objects. It makes finding the root cause of each incident and the other way around intuitive for the team members. If your project needs more extensive options, try our Extension for Jira Service Management. It provides its users with additional fields, attachments, and views that help make sure all important information is included. 

Post-incident reviews (PIR) support uncovering weak spots in your service and decrease the time of incident resolution. Documenting incidents informs how similar issues should be handled in the future. With post-incident reviews in Jira Service Management, teams can create long-term solutions to problems. To turn on the feature, navigate to Project settings and Features, and then click on Post-incident reviews under ITSM categories. To create a new report select Create in the top menu bar and choose the post-incident review request type from the drop-down list. After filling out the required information, connect the incident to the PIR in the linked issues field.

Opsgenie provides its users with notification mechanisms. Teams can automatically create alerts that include detailed information about the issue. The Atlassian tool makes it possible to set up on-call rotations, schedule features, and alert escalations to ensure the best incident management. When users execute actions on the Opsgenie notifications, issues in Jira Service Management automatically update with comments about these actions. If users close the alert, the issue in Jira Service Management is resolved. You can find the information on how to set up Jira Service Management and Opsgenie on Atlassian Community. 

Incident management is a crucial ITSM process. The neglection of incidents impacts customer satisfaction and can increase the overall project cost. There are some solid steps to follow to perform the incident management process in accordance with ITIL guidance. Along with the good practices, it results in better time management, quicker updates or fix releases, and most importantly: the client’s trust. In order to provide high-level service, the team members need the right system to support themselves. One of the best tools for this purpose is Jira Service Management. Thanks to its wide range of ITSM functionalities and integrations, Atlassian’s software will intuitively guide your team to deal with incidents quickly and efficiently.