Managing incidents with your IT service desk

Still need help?

The Atlassian Community is here for you.

Ask the community

An incident model helps service desks investigate, record, and resolve service interruptions or outages. An Information Technology Infrastructure Library (ITIL) incident management workflow aims to reduce downtime and negative impacts. 

Incident management focuses on short-term solutions. To manage reoccurring incidents or underlying problems, see Managing problems with your IT service desk.

The IT Service Desk template comes with an incident management workflow. This workflow ensures that you log, diagnose, and resolve incidents. We recommend you start with this workflow and adapt it to your business needs.

When managed well, incident records can identify:

  • missing service requirements
  • potential improvements
  • future team member training

This page describes some best practices for managing incidents using JIRA Service Desk. You may seek formal training in how to make ITIL recommendation work best for your business.

On this page

Incident management process

The IT Service Desk template associates certain requests with an incident workflow. We set up the workflow to complement the following incident management process. We recommend you start with this workflow and adapt it to your specific needs over time.

The ITIL incident management process, in brief:

  1. Service end users, monitoring systems, or internal IT members report interruptions.
  2. The service desk describes and logs the incident. They link together all reports related to the service interruption.
  3. The service desk records the date and time, reporter name, and a unique ID for the incident. JIRA Service Desk does this automatically.
  4. A service desk agent labels the incidents with appropriate categorization. The team uses these categories during post-incident reviews and for reporting.
  5. A service desk agent prioritizes the incident based on impact and urgency.
  6. The team diagnoses the incident, the services effected, and possible solutions. Agents communicate with incident reporters to help complete this diagnosis.
  7. If needed, the service desk team escalates the incident to second-line support representatives. These are the people who works regularly on the effected systems.
  8. The service desk resolves the service interruption and verifies that the fix is successful. The resolution is fully documented for future reference.
  9. The service desk closes the incident.

Team members should carry out post-incident reviews for major incidents. These investigations can help determine:

  • missing requirements
  • potential changes to service level agreements
  • potential service improvements or focus areas


Set up incident management in JIRA Service Desk

Configure the workflow and fields with the Incident Management workflow add-on

We used the ITIL framework to build the following workflow add-on for incident management: https://marketplace.atlassian.com/plugins/com.atlassian.servicedesk.incident/server/overview

You can use this workflow as a template for your own incident management process.

To use the workflow from the Marketplace:

  1. Log in as a user that has the JIRA administrator global permission, and follow the instructions listed here to import a workflow.
  2. To add the workflow fields to your incidents, activate the screen by following the instructions here: Defining a screen.

Incident management workflow





Default form fields for incident reports

JIRA Service Desk allows you to customize the fields of information collected from customers. Additionally, you can customize the fields of information used by your agents. JIRA Service Desk does this through issue type fields and screens. Fields  help agents  investigate, assess, and categorize the incident for reporting or querying.

By default, we include the following fields in your agents' view of an incident. If needed, you can  add  custom fields. Find out more about fields in JIRA.

Field name

Description

SummaryA short description of the request.
ReporterThe person who submitted the request.
Component/sSegments of your IT infrastructure that relate to the request. For example, "Billing services" or "VPN server". These are used for labeling, categorization, and reporting.
AttachmentFiles or images added to the request.
DescriptionA long, detailed description of the request.
Linked IssuesA list of other requests that affect or are effected by the request. If your business uses other Atlassian products, this list may include linked development issues.
AssigneeThe team member assigned to work on the request.
PriorityThe importance of the request's resolution, usually in regards to your business needs and goals. Sometimes, priority is calculated by impact and urgency.
LabelsA list of additional custom labels used for categorizing or querying records.
Request participantsA list of extra customers who take part in the request, for example, people from other teams or vendors. Read more about participants.
ApproversA list of people responsible for approving the request, usually business, financial or technical contacts .  
OrganizationsA list of customer  groups interested in the request's resolution.
ImpactThe effect of the incident, usually in regards to service level agreements.
UrgencyThe time available before the business feels the incident's impact.
Pending reasonA short description or code that indicates why the incident is not progressing.
Product categorizationA category of IT asset or system that the request effects.
Operational categorizationA category of action or function required to fulfill the request.
SourceThe asset or system where the incident originated.

Learn more about IT service management (ITSM)

Get more tips and tricks for successful ITSM, view case studies, and learn how to take your service desk to the next level. Check out the ITSM resources on IT Unplugged.

Last modified on Mar 14, 2018

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.