Is it an Incident or Service Request?

May 6th, 2016 | Posted by Don Boylan in Incident Management | ITIL | Service Request Management

Face PalmA funny thing happened many years ago when I was taking my first ITIL course. It was a v2 Foundation course that I attended in Phoenix as part of a Pink Elephant conference on implementing ITIL. The class was delivered by one of the best instructor’s I have ever had the opportunity to be in class with (Hi Jennifer!!!) but at some point in the class, we stopped learning.

Maybe it was the heat (the temperature outside was near 110 F), maybe it was the desert air evaporating our brains. Whatever it was, our instructor had just gone through Incident Management and was starting up on Service Request Management and we didn’t get it. As a whole, no one in our class could understand the difference between an Incident (something’s broken) and a Service Request (nothing is broken, the user just needs assistance).

After giving us the definition of each and a thorough intellectual discussion regarding their differences, the instructor was at a loss. She pulled up a chair, sat down, put her hand over her face, and asked us to present her with situations and she would tell us if the situation we described was an Incident or a Service Request.

After about 10 minutes of us presenting various scenarios, and her explanation of why each one was either an Incident or Service Request, we finally clued in to the difference.

So let me put some situations to you and see if you can differentiate whether it is an Incident or Service Request.

Scenario #1: Is it an Incident or a Service Request?

Printer catches fire.

And the answer is: Incident. Ok that one was pretty easy. Obviously smoke coming out of any IT device is a break/fix situation.

Scenario #2: Is it an Incident or Service Request?

A user needs help creating a pivot table in Excel.

And the answer is: Service Request. Again, pretty easy. Nothing is broken. Excel hasn’t stopped being able to create pivot tables, the user just needs to be informed on how they work.

Scenario #3: Is it an Incident or a Service Request?

An account is locked out due to too many password attempts.

And the answer is: Challenging. I put this question to my classes when I was an ITIL instructor and about half of the participants said Service Request and half said Incident.

The difference between an Incident and Service Request is that in an Incident something is broken and for a Service Requests nothing is broken (but the user is unable to perform their work for some reason or another). In looking at a locked account, what is broken? Nothing is broken so the answer is: it is a Service Request.

The security system locking the account to prevent a possible intrusion is the security system working the way it was designed. If the security system hadn’t locked the account after multiple incorrect attempts, then that would be an Incident (a very serious class of Incident typically called a Security Incident).

By the way, I find it very irritating that some IT organizations make users jump through hoops if they start a Request out in an Incident ticket or visa-versa. If a user opens an Incident through a self-service portal to request that some software be installed, do not respond back three days later telling them the ticket has been canceled because they did it wrong. As a service organization, take it on yourself to open the Service Request on their behalf. If there is information missing needed to process the Service Request, then politely send them an email asking for the missing information. At that time you can tell them the proper process for submitting Requests in the future, but don’t punish them for initiating a Request through the wrong channel. That’s just mean and petty.

You can follow any responses to this entry through the RSS 2.0 You can leave a response, or trackback.

One Response

  • Stan Eads says:

    Back in the day (as Service Desk and Service Request were just coming to be), Incidents were only logged and addressed by tier-2 support. That remains the easiest way to handle this confusion, without having to have every employee in your organization understand the subtleties of the differences between an Incident and a Service Request.

    Simply put, have the Service Desk (tier-1 support) log ALL tickets as Service Requests. In my experience (starting in 1984) the tier-1 support staff is often not able to determine whether the caller’s problem is due to a service delivery failure or local problem specific to that user. If tier-2 determines that it is indeed an Incident, they can log an Incident report, linked to those tickets that were escalated by tier-1.

    In addition, with the redundancy that is engineered into our IT components these days, most Incidents are never noticed by the users at all (as in the case of a failed disk in a mirrored pair, as ITIL itself cites as an example in v3). The Service Desk never hears of them, and would not be involved in logging them. Noticing and fixing such Incidents would is a tier-2 function. In modern IT organizations, a large majority of Incidents have little or no user impact. (Also note that doing things this way eliminates the irritating trend toward logging EVERYTHING done by the Service Desk as an Incident: ordering a laptop, requesting a conference room change, etc.)



Leave a Reply

Your email address will not be published.