Overview
The following provides an overview of the Information Technology Infrastructure Library (ITIL) definitions of classification types, provides sample use cases, and provides additional notes regarding how these classifications are used within Enterprise Service Management (ESM).
For some, the distinction between Service Request and Incident is often quite blurry with strong disagreements between a department's employees. The definitions below are based upon the latest ITIL framework guidance, and is a generally recommended best-practice. While it is not necessary for different departments to agree on the distinction between the two classifications, it is important that within any specific ESM ticketing application that the classification is used consistently by all individuals with access to that ticketing application.
Note
Every ticket created must have the correct classification type.
Ticket Classification Definitions
-
Service Request
-
A request from a customer for information, or advice, or some existing service to be provided. Service Requests are usually considered standard operational tasks/efforts, and do not require an Request For Change (RFC) to be submitted. Service requests are not as urgent as incidents, major incidents, or problems, and they can be scheduled in accordance with existing work priorities.
Examples include:
- Resetting a password.
- Setting up a computer for a new employee.
- Request for training on a product or service.
- Processing an employee's travel request.
-
Incident
-
An unplanned interruption to a Service, or a reduction in the Quality of a Service. Failure of a Configuration Item that has not yet impacted one or more Services is also an Incident.
Examples include:
- A person's computer will not start
- A person is normally able to access a UA web service, but it is suddenly returning errors
- Network disruptions
- A server is down
-
Major Incident
-
An event which has significant impact or urgency for the business/organization and which demands a response beyond the routine incident management process.
Tip
This classification type is typically only enabled in ticketing apps used by IT, and Facilities departments.
A major incident will be an incident that is either defined in the major incident procedure or which:
- may either cause, or have the potential to cause, impact on business critical services or systems (which can be named in the major incident procedure);
- or be an incident that has significant impact on reputation, legal compliance, regulation or security of the business/organization.
Examples include:
- A widely used UA web service is down, and many people are not able to login
- A technical glitch is affecting a crucial feature and many people have reported this
Major Incident tickets should be created from reported Incidents, based on the number or severity of incoming reports. This can be particularly useful for service desks to keep track of ongoing issues that might generate multiple tickets.
-
Change
-
Tip
This classification type is typically only enabled in ticketing apps used by IT, and Facilities departments.
The addition, modification, or removal of anything that could have an effect on IT System. The Scope should include all IT Services, Configuration Items, Processes, Documentation etc.
-
Problem
-
Tip
This classification type is typically only enabled in ticketing apps used by IT, and Facilities departments.
A cause of one or more Incidents. The cause is not usually known at the time a Problem Record is created, and the Problem Management Process is responsible for further investigation.
It is important not to confuse Incident management with Problem management. Incident management is focused on resolving issues as soon as possible and restoring service back to normalcy, whereas problem management is primary focused on providing either a viable workaround for a recurring incident/issue, or a permanent resolution.
-
Release
-
Tip
This classification type is typically only enabled in ticketing apps used by IT departments.
A collection of hardware or software documentation, processes or other components required to implement one or more approved changes to IT services. The contents of each release are managed, tested, and deployed as a single entity.
Use in Enterprise Service Management
Since these definitions may not perfectly suit the processes of a specific department, these various classifications can be be renamed, or turned on or off as necessary on a per ticketing app basis.
In the below illustration, the interior blue sections of the pyramid show the hierarchy of what can be used as parent or child tickets in ESM.
A parent ticket can contain any of the child ticket classifications below it. This means that a release can contain any problems, for example, without a change between them in the hierarchy.
When a parent ticket (for example, a release) is updated, a technician can elect to update or close all the child tickets (for example, incidents or service requests) that are nested within it.
If a ticket is converted to a project task, any existing parent linkage is removed; however, children tickets will remain. Updates made to the ticket based on the corresponding project task's status will no longer be able to cascaded to its children.
Lastly, per the outer edges of the diagram, any classification of a ticket may have a service, knowledge article, asset, or configuration item associated with it.
Is there any additional information I should know about?
If the wrong ticket classification type is used, change it to the correct type. Instructions can be found at Change Ticket Classification
Need additional help or have issues
For support, requests may be submitted anytime by Requesting Support for the Enterprise Service Management service. Support Requests are worked by Priority based on the Impact and Urgency of need as well as the order they are received by the IT Employees with the knowledge and permissions to assist with the request.
For immediate assistance please review the Contact Us page for ways to contact the appropriate support group.