In the second set in the incident management lifecycle series, we look at the very basic distinction that distinguishes incident from a service request.
Often, most organizations confuse (some on purpose) incidents with service requests, and both are handled with the same rigor. This keeps things simple, but in hindsight, it does more bad than good.
Let’s discuss why it is better to keep them separate, and how to go about it.
The Story So Far
This is the second article in the series. In the first one, I introduced the incident management lifecycle workflow and discussed the incident management triggers in detail. Once an incident is detected based on the trigger, an activity needs to be undertaken if the detected incident is indeed an incident and not a service request.
This distinction does not arise for triggers based on event management, but rather for user and staff raised incidents, more so with the ones triggered by the users.
To understand the importance of this check, let us first revisit the differences between an incident and a service request.
Incident vs Service Request
An incident is a disruption to a service that is enjoyed by the user. For example, if the user enjoys the internet service, and if it goes down for whatever reason, this can be termed as an incident.
A service request is an add-on service or enhancement to a service, as requested by the user. For example, if the user does not presently have access to the internet service, he/she needs to place a service request for getting internet access. The user cannot raise an incident for getting internet access.
Service requests are not triggered from disruption to any services or downtimes. But rather it is triggered by the requirement of the user to enjoy a new service.
Service requests are managed exclusively by the request fulfillment management process.
Why should Incidents and Service Requests be Handled Differently?
An incident is a disruption to a service, so it potentially affects the work activities of the user. So, when the user raises an incident, it necessitates the need to fix it on priority.
A service request is an add-on that the user requests for. So, when the user raises a service request, the priority may not be as high as the incident if all priorities were to be weighed in on a single scale.
Say, for example, a single team handles incidents and service requests. Two incidents and two service requests show up at their doorstep. Which one should they handle first? I bet you guessed it right. The incidents, as they potentially could impact the productivity of the user. Once the incidents are resolved, the team can get to the service requests. It is not going burn the house down!
What Happens when Incidents and Service Requests are Handled in the Same Way?
Some organizations don’t distinguish between the two, and they handle both in the same manner – in the same bucket – in fact, all are just called as incidents. What are the consequences?
The biggest drawback is that the IT staff won’t be focused towards what is more important. They could get distracted by items that rank lower on priority rather than where the need is more.
Consider this example. If a house is burning, would the fire tenders rush to douse the fire, or do they head over to install a new pumping station in the city. You know the answer! So, it is highly recommended that incidents and service requests are well defined, and handled in a manner that focuses on priority items first.
Classic Argument against Incidents vs Service Requests Separation
Some smart alecks have often asked me this question – suppose a user needs to get a new service to carry out his work – which is a service request. Without the new service, he cannot work – which means that he is unproductive. Shouldn’t this quality service requests be handled as incidents?
The answer is NO. Owing to a case where zero planning was involved is not a valid argument to balance the incident and service request scales. The user in question should have planned better. The user should be aware of the SLAs and should have put in his/her request well before the deadline. Putting it in the eleventh hour, and expecting incident-like treatment is a futile exercise.
What’s Next
In the next article in the incident management lifecycle series, I will discuss the incident logging process activity in detail.
