If you’ve ever waded through long threads on LinkedIn ITSM forums, you probably know that there are few other questions that result in so many line-in-the-sand positions.
But why? If you use ITIL® as the best-practice basis for your IT Service Management (ITSM) architecture and vocabulary you could be forgiven for thinking this would not be an issue.
ITIL defines an Incident as:
“An unplanned interruption to an IT Service or a degradation in the quality of an IT Service”
while a Service Request is:“Any action oriented-communication (from a service user) that is not an Incident”.
(ITIL also identifies an Incident as “Failure of a Configuration Item that has not yet affected Service”, but that type of incident has absolutely no impact on your Customers and service users and is never part of this issue.)
The only time there is ever any dispute about whether something should be an incident or a service request is when a user (ITIL’s rather unfortunate term for a consumer of your services) contacts the service desk with something that requires action.
The differentiation must be made
When this occurs, the service desk will open an electronic ticket to record this and help manage it through to some conclusion and closure. A service desk ticket will, in most IT environments, be designated as either an incident or a service request; it must be one or the other. No action can be taken on the ticket until this designation has been decided.
What causes the concern is that the formal ITIL definitions of the terms incident and service request don’t fit with how people generally interpret those terms.
Most people would understand the term ‘service request’ as representing something that they have asked to be supplied to or done for them, but NOT for something that you are obliged to do for them, and NOT for complaints, suggestions or compliments. Yet in the ITIL scope of the Service Request, it can encompass all of these.
Most people would understand the term ‘incident’ as referring to something bad that happens and affects them. But in the ITIL scope of the term, it is only an incident if that bad thing is something that you (the service provider) were responsible for causing.
Who does it matter to?
The distinction between incidents and service requests is vitally important to you as a service provider, not in the sense that one is more important than the other (you can easily come up with examples of utterly trivial incidents and top priority service requests) but rather that, ultimately, you will apologize for every incident and you will never apologize for a service request (unless you mishandle it, and then you will create an incident to deal with it).
When I say ultimately, what I’m referring to is the reporting that you, the service provider, owe to your customers. Typically, once a month, someone who represents you (a role ITIL calls the business relationship manager) will sit down with a customer and review the service experience. Every incident that affected the customer, or any of its service users, will be reported along with its impact, what is known about its cause, and what is being done to prevent or mitigate future occurrences. And you will apologize for each.
You will then review all of the service requests you have handled over the period, both the ones that you are contractually obliged to handle (usually having agreed performance targets) and the unpredictable ones (including questions, complaints, suggestions, and accolades). The latter category should be thought of as a set of business opportunities that should be discussed with the customer to search for improvement potentials in the services or the relationship. But no apologies are warranted for service requests of either type.
Therefore, it is critical for you and your customers to agree on the difference between incidents and service requests and deal with them as two separate categories in your service reviews. Of course, you and your customers also need clear agreements on exactly what your service obligations are, but that is a completely separate topic.
Priority is the key factor
While people in your service provider environment should know the distinction between incidents and service requests, they should never be concerned about whether a task they are working on is related to an incident or service request. What they MUST ensure is that, at any given time, if they can be working on more than one task that they are working on the task with the highest priority.
But that leaves us with the divergence between what you as a service provider (and your customers) understand as the difference between an incident and a service request, and how your service consumers understand those two terms.
Two potential solutions are non-starters. It is not appropriate (or even possible) to get your service consumers to use ITIL terminology. Nor is it viable for you, internally, to use the service consumers’ fuzzy day-to-day meaning of those terms.
Keep the distinction in-house
The only real option is to keep the incident and service request distinction a matter between you and your customers, and NOT expose it to the consumers of your services. This can be accomplished simply by using a generic, neutral term like ‘service desk ticket’ in all conversations with your Service Desk staff (and by all other service provider personnel) when dealing with that community. Also, where you allow the user community to access those tickets directly, ensure that the view they have does not distinguish between the two categories.
The bottom line is that you, as a service provider, need to clearly understand the distinction between incidents and service requests, need to agree with your customers on the distinction, but are best served by NOT exposing that distinction to your user community.
Originally published Feb 20, 2016 16:51, updated May 27, 2022
