Problem management process
The IT Service Desk template comes with a problem-management workflow. We set up this workflow to complement the following problem management process. Use the workflow to transition problem registers alongside these ITIL recommended activities:
- problem investigation
- identification of workarounds
- recording of known errors
We recommend you start with our default workflow and adapt it to your specific needs over time.
The ITIL problem management process, in brief:
- Incident trends, vendors, or technical support staff report problems to the service desk.
- A service desk team member records the details of the problem and links all related incidents.
- A service desk agent labels the problem with appropriate categorization. They may reuse the labels of the incidents linked to the problem. The team uses these categories during review and for reporting.
- A service desk agent prioritizes the problem. They base priority on the frequency of related incidents and their impact.
- The service desk team determines the root cause of the problem.
- The service desk team records the workarounds used to resolve related incidents. These workarounds to reduce service interruptions until the service desk fully resolves the problem.
- The service desk team adds known errors to their knowledge base. They include symptoms of related incidents and relevant workarounds.
- The service desk team proposes a change to the infrastructure to resolve the problem.
- The service desk closes the problem.
Team members should carry out in-depth reviews of major problems.
Jira Service Desk's default problem workflow
Your service desk agents can create an issue using the Problem issue type. This puts the problem record into the recommended problem workflow.
The workflow follows the basic process above. You can customize it to adapt to the needs of your business.
Customize your problem workflow
In your service desk project, select Settings () > Workflows.
- Select the edit icon (a pencil), in the entry titled Problem Management workflow for Jira Service Desk.
- Use the workflow editor to add or remove steps and transitions.
Document known errors in your linked Confluence knowledge base
Create a restricted section of you Confluence knowledge base that holds known error records. Agents can quickly find and execute workarounds for future incidents. This:
- restores services quickly
- reduces duplicate efforts
- avoids unapproved or dangerous workarounds
- and more
Known error records define the problem and its root cause. These records capture any known symptoms of the incidents involved. They detail workarounds and their status (temporary or permanent).
Here's an example of a known error record:
Default form fields for problem 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 problems for reporting or querying.
By default, we include the following fields in your agents' view of a problem. If needed, you can add custom fields. Find out more about fields in Jira.
|Summary||A short description of the request.|
|Reporter||The person who submitted the request.|
|Component/s||Segments of your IT infrastructure that relate to the request. For example, "Billing services" or "VPN server". These are used for labeling, categorization, and reporting.|
|Attachment||Files or images added to the request.|
|Description||A long, detailed description of the request.|
|Linked Issues||A 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.|
|Assignee||The team member assigned to work on the request.|
|Priority||The importance of the request's resolution, usually in regards to your business needs and goals. Sometimes, priority is calculated by impact and urgency.|
|Labels||A list of additional custom labels used for categorizing or querying records.|
|Request participants||A list of extra customers who take part in the request, for example, people from other teams, or vendors. Read more about participants.|
|Approvers||A list of people responsible for approving the request, usually business, financial or technical contacts.|
|Organizations||A list of customer groups interested in the request's resolution. Learn more about organizations in Jira Service Desk.|
|Impact||The effect of the problem, usually in regards to service level agreements.|
|Urgency||The time available before the business feels the problem's impact.|
|Source||The asset or system where the problem originated.|
|Investigation reason||The trigger for prompting an investigation. For example, reoccurring incidents, non-routine incidents, or other.|
|Pending reason||A short description or code that indicates why the problem is not progressing.|
|Product categorization||A category of IT asset or system that the request effects.|
|Operational categorization||A category of action or function required to fulfill the request.|
|Root cause||The original cause of the incidents related to the problem.|
|Workaround||The detailed description of a temporary, known solution to restore a service. If you have Confluence, we recommend you document your workaround in your knowledge base.|