freshservice-incident-vs-service-request

Incident and Service request: How are they different?

Written by on November 6, 2014

The line between an incident and a service request is often quite blurry and causes even the hardcore ITIL geeks among us to explosively disagree. 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 under incident management. But with the launch of ITIL v3, the framework most service desk software today is based on, incidents split into two categories: service requests and incidents. This differentiation was also accompanied by the new process of request fulfillment, which was introduced specifically to manage service requests.

The Significant Difference

ITIL v3 defines an incident as ‘an unplanned interruption to an IT service or reduction in the quality of an IT service.’ When everything works exactly the way it’s meant to, the service in question operates without a hitch. But when something doesn’t, it causes ‘unplanned interruptions’ to the service and creates an incident. So the main goal of Incident Management is to provide a quick fix that resolves the interruption and restores the service to its full capacity. These interruptions can be anything from your computer not booting up to the WiFi not working.

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 a software.

Another thing that distinguishes service requests from incidents is that service requests, more than incidents, have a higher possibility of including pre-approved or standard changes. These are the changes which are relatively low risk and don’t require a long process of perusal and approval. For instance, let’s say that it is company policy at an organization to provide every employee with additional memory space when they run out. If this is the case and an employee wants to request for extra memory, this is a service request and also a pre-approved, standard change that doesn’t require any further study to be granted.

To Summarize

Identifying these kinds of pre-approved changes in advance can be a huge time saver. This is where distinguishing between service requests and incidents can help you run things better. 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 incident management 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!

One of the most frequently asked questions to us is the Difference between CMDB and Asset Management

We also have our 2 cents to share about the service catalog here.

Get in on pro tips and hacks to transform ITSM.

  • stantonl

    Jyotsna, I have to disagree with you about ITIL v2 not differentiating between Incident and Service Request. The v2 definition is “An event which is not part of the standard operation of a service and which causes or may cause disruption to or a reduction in the quality of services and Customer productivity.”

    It’s quite clear from this that a user who forgot a password and needs a reset (for example) is part of standard operations of a service and therefore is not an Incident. That’s less clear in v3, since one might argue that a user who forgot a password has had his work interrupted, and therefore it is an incident.

    Either way, Incident tracking should give meaningful measurement of the quality and delivery of IT resources. Lumping in user errors and laptop questions skews the numbers with non-relevant data and makes meaningful analysis difficult or impossible. Service requests and IT incidents need to be separated or the value of the information is reduced or eliminated.

    Stan