Support queries are processed in Matrix42 Service Desk as tickets. This is an electronic type of problem that is reported by a customer. The "Ticket" and "Incident" terms are often used with the same meaning, which is incorrect and leads to misunderstandings in relation to compliance rules. A Ticket is a generic term for a configuration item of type Incident, Problem, Change, or Task. An incident is, therefore, a special kind of ticket. It means every incident is a ticket, but not every ticket is an incident.
Types of Tickets
Matrix42 Service Desk provides you with three different types of tickets for classifying your support queries. By using these tickets, you can also map the lifecycle of a support query in the system.
- Incident: An incident is reported by a customer that does not belong to the standard operation of a service and actually or potentially causes an interruption or reduction of service quality. An incident is the first instance in service management for which the support employee creates a ticket. If the incident can be sorted out immediately, the ticket and the incident are closed. If it is not possible, the support employee can convert the incident into a problem or a change.
- Problem: A problem is an unknown cause of one or more actual or potential incidents. Problems are often first identified by the occurrence of several incidents with similar symptoms.
- Change Request: A change request is a planned, usually extensive, change to a system. The purpose of a change request is to remove the cause of a problem.
- Task: A task is an instrument that is used in the division for coordination of teamwork and delegation of work. It can also be used for your own re-submissions. Tasks can also be sub-elements of incidents, problems, or changes. As a result, several people can easily work on complicated tasks.
What’s the Difference between Incidents, Service Requests, and Tickets?
As per ITIL v2, there was no such differentiation, to begin with. All the issues and requests raised by users were collectively grouped together as incidents. But with the launch of ITIL v3, incidents split into two categories: "service requests" and "incidents". We decided to deliver "Incident" and "Service Requests" looking nearly the same, to give every organization a chance to configure the process to fit their specific business needs. In order not to ruin the current process of Service Desk, support of "service requests" is delivered deactivated, and a customer needs to turn it on manually in Service Desk settings.
What is an Incident?
Most everyone is probably familiar with your traditional incident. Well, ITIL v3 defines an incident as ‘an unplanned interruption to an IT service or reduction in the quality of an IT service’. We like to define an incident as something that is a break/fix issue that needs to be resolved. This might be something that is not working properly or could be broken. For example, this would include a broken printer, an application that will not load properly, your computer not booting up, or WiFi not working.
What is a Ticket?
When an incident occurs, a user submits a “ticket.” The service desk works the ticket according to workflows the organization has set up to classify it as an "incident" or "service request". For end-users, the classification does not matter; they just want to get a solution for the ticket they submitted. Therefore, in the Self Service Portal, although end users will still see Tickets, Incidents and Service Requests they reported, they will be able to report Tickets only.
What is a Service Request?
Service Requests, however, are defined as ‘a formal request from a user for something to be provided – for example, a request for information or advice’. In other words, a service request is raised when you want to procure something that you don’t have in the first place. Be it access to the printer or upgrading to a higher version of the software.
That means a service request is a request for service that your organization can offer to its end users. You have the option to build service catalog items which can include various information that can be collected from your end-user as well as a “behind the scenes” process that includes tasks and approvals that will be sent off to certain groups within your organization. The service catalog can be used to build out request forms for employee onboarding and offboarding, various equipment or an office move. You may even find your end-users requesting shore leave through the service catalog. The service catalog will save you time with upfront data collection and automatic tasks or approvals.
By categorizing and resolving pre-approved IT changes as service requests, you can ensure that they do not enter an unnecessarily complicated workflow. Also, once you create a strong service request system, you can initiate self-service by adding on a service catalog that can be utilized by your users to select the exact service that they need. And finally, distinguishing between incidents and service requests can help you in the long run too, because it enables your team to identify the nature of tickets you’re receiving and to decide where your resources are best allocated. This will also help you in reducing your service desk agents stress!
Activating Support for Tickets and Service Requests
In the Service Desk settings, execute action "Enable Tickets and Service Requests":
After enabling, the following changes will be applied:
Will be enabled
- Tickets Navigation Item in Self Service Portal application
- Tickets Navigation Item in Service Desk application
- Service Requests Navigation Item in Service Desk application
- Action Transform for Tickets in Service Desk application
- Action Transform for Service Requests in Service Desk application
- Action Transform for Incidents in Service Desk Application
- Ticket related items at Landing Page in Self Service Portal and Service Desk application
Will be disabled
- Incidents Navigation Item for Self Service Portal application
- Incident-related items at Landing Page in Self Service Portal application
- Direct Incident Creation from Service Desk application
Tickets, Incidents, and Service Requests Management in Service Desk
After enabling the feature, a Service Desk employee can find new Tickets and Service requests in navigation. Incidents are still visible.
By default, Self Service Portal users will create Tickets and Service Desk employees can edit them and apply Transform action to turn them into Incidents or Service Requests. Therefore, when classifying existing Tickets, Transform action needs to be used.
When a Service Desk employee creates a new Ticket and already knows the type, Service Request or Incident, he or she can select an option in the Classification picker. This will change filters for the Service Level Agreement, Responsible Role, and Category and may suggest more suitable items.
If it is not clear if the Ticket is an Incident or a Service Request, it can be classified later using Transform action:
The Transform wizard suggests a more suitable Category, Service Level Agreement, and Responsible Role depending on the target ticket type.
If a ticket uses other Category or Responsible Role than assigned by the default settings, the Transform wizard keeps Category or Responsible Role that were set manually (e.g. when creating or editing the Ticket).
Service Level Agreement is auto-suggested according to the target ticket type.
Further, Category, Service Level Agreement, and Responsible Role can be changed manually directly in the wizard.
Make sure that the Incident, Ticket and Service Request Configuration Items contain the same data definitions when there was Customizing implemented. Otherwise, transformation will fail.
Support by E-mail Robot
After enabling support of Tickets and Service Requests, it becomes possible to configure the E-mail Robot mailbox to import Tickets and Service Requests as well.