Which comes first? Incident or Service Request

[rpmason]

From another topic

What we call as incidents are also service requests in more ways than one.

Interesting. When I was taking my IPSR and again when taking my Service Managers courses, I talked to the instructors about how it was easier for me to think of an Incident as another type of Service Request.

Both times, the answer was STOP thinking that way.

Maybe they didn't want to encourage that thinking before the V2 tests. In V2, the Service Request procedure is just an odd little tangent off the Incident procedure.

Or is it just a game of which came first? Does it really matter? If I sound snarky, I don't mean to be. I'm actually curious about what people think as opposed to what's in the V2 books.

[thechosenone69]

RP,

ITIL V3 has broken the two up into separate and distinct categories. An incident is an incident which is not planned and means that the service is being disrupted,

Where as a Service Request has a planned process or procedure ready to be executed. ex: new equipment, training etc.

Incident -> My PC is not working
Service request -> Add toner to the printer

In ITIL V3(I still hate it) made things clearer. They said that a Service Request should not be classified as an Incident or a change. So if the call comes to the service desk and its a service request then its a different process with seperate activities which is called a service request.

[aucade]

In v3 the process is "Request Fulfilment". As thechosenone69 pointed out, Service Requests have a defined procedure ready to be executed. They could be procedures which involve multiple departments (ie IT, HR, Purchasing Dept.,...) and/or multiple authorisation steps. They also generally have a timeline from n days, always depending on how many instances are involved.

Typical SR`s based on a self service interface which we all know from the internet are "shopping carts" ala Dell, Online banking etc.

[Timo]

So in the end, doesn't it all come to defining which "items" are SRs and which are Incidents? Depending on your definition, Incidents too can be (to a degree) managed through a self service portal. Personally, I don't care much what they are called. In both instances it is user/customer needing something and support organization has to capture/detect that need, record it, and then put it through a "give the customer what he/she wants" process.

IT Skeptic has an interesting piece about Response Management on his ITSM Watch blog. Worth a read, IMHO.

[Anticlue]

Hi All,

In practice, I'd agree with Timo and suggest service requests, incidents differ based upon the nature at the item.

For example, a new employee needs an account. That would be request fullment, service request. However for that already created account the individual forgets their password, this would be an incident.

The lines become blurred because with password management there are now tools which enable users to reset their own password based on other things they know to identify themselves. Hences if the tool exists within the organization it is a service request through request fullfment.

Hope this helps,

[Diarmid]

the distinction in the terms, or the lack of it, is context sensitive.

If you want to regard "my machine is broken" as meaning "please fix my service" that can work perfectly well as regards efficiency and effectiveness in getting the machine fixed, always assuming the underlying procedures are geared up properly. After all, these underlying procedures don't care what you call the thing.

However, there still needs a way of recording that the service was deficient so that you can measure the quality of your service and both persuade the customer that it has been adequate and strive to improve it. So these "service requests(to restore service)" need to be flagged and counted in a way that other service requests do not.

One fairly reasonable approach to a portfolio of services that can be made available on request is to provide them under procedures that are designed very specifically for just that service. This ensures that they are provided slickly and reliably and enables the monitoring and management of demand etc. The thing about a "please fix my service" type of service is that it can only be governed by much more generic procedures which have to contain a great breadth of possible circumstances.

It is perfectly possible and legitimate to raise an incident before any user has been impacted. since one tends to think of a service request as emanating from a requester, there may be some shuffling done in the system to "fake" a request. (I know that some people have spoken before as if that were true of incidents as well, but that seems to be a result largely of their struggles with their incident management software.)

"Please fix my service" has to be subject to immediate evaluation as to timing and priority through impact assessment. Other service requests can have pre-agreed impact and may therefore be treated slightly differently.

By the time you have accommodated these and any other distinctions that come to mind, do you still have a benefit in calling incident reports service requests?

For sure, responding to an incident report and responding to a service request require the same attitude and focus on the customer requirement and are both part of the service to be delivered. But I suspect that understanding that fact is sufficient convergence for most organizations.

[viv121]

ITIL has historically been descriptive and not prescriptive. In Diarmid's example " Please fix my machine", isn't it a service request where the customer is requesting service from the service desk. The service desk might open an incident and try to immediately fix the issue, try to give a work around or escalate to higher level of support. These are indeed incidents which is essentailly defined as failure or degradation in existing services. What we are confusing with is a service request and a new service request. A service request aka an incident could be about fixing something which is broken and a new service request is about providing something which was never there. This is one of the reasons that the users are given a hotline number to report what is broken while they are normally given a self help tool in order to make their own new service request which follows a workflow of user's manager's approval, procurement manager's approval ( need based), license management's approval ( again need based) and finally helpdesk's manager's approval.

V2 and V3 (I've never been fond of it) both tell about a request for service and a new service request.

[Diarmid]

Viv,

v.2 is pretty vague and generic in its use of "service request" The glossary definition leaves many questions unanswered and I don't think it is used entirely consistently through the manuals.

v.3 I cannot properly speak for as I do not have access. However the "An Introductory Overview of ITIL V3" version 1 (2007) gives the following definitions;

Incident
"An incident is an unplanned interruption to an IT service, or a
reduction in the quality of an IT service. Failure of a
configuration item that has not yet impacted service is also an
incident."

Service Request
"A service request is a request from a user for information or
advice, or for a standard change, or for access to an IT service."

Note that "change request" is not included in this definition. If "new service request" actually is intended to mean a request for a new service, then that could be considered a form of "change request". there is, of course, a whole other discussion on "standard change".

If we also take the word "access" to include the running of an ad hoc service whether interactive or batch, then these definitions seem reasonably useful.

This almost allows us assign any service desk call into one of two or three categories, those related to incidents and those that are requests. Personally, I like at least four (I think I once thought of a fifth, but can no longer recall it - maybe it is "wrong number") to assist in good management information and control: incident report, change request, service request and information request.

Such categorizations are of course subject to circumstances, particularly the scale and complexity of the IT services environment in question and I would expect to come to a different arrangement in different organizations.

I'm inclined to say this came straight out of ITIL (the original) because, although I do not think it was said explicitly, I derived it from considering how to apply the best practice guidance I received by studying it.

[rayfleming]

Interesting thread.

Given that a Service Request is [ITIL v3] is
"A service request is a request from a user for information or advice, or for a standard change, or for access to an IT service."

What would a password reset be classified as, an incident or a request? On the one hand someone cannot access the service (e.g. an online application) because their password is no longer valid (is that a service disruption?) or is it simply that the service is being provided (i.e. the online application is available) but can't be accessed.

[Diarmid]

What would a password reset be classified as, an incident or a request? On the one hand someone cannot access the service (e.g. an online application) because their password is no longer valid (is that a service disruption?) or is it simply that the service is being provided (i.e. the online application is available) but can't be accessed.

Why wring hands and anguish over this?

For the most part there is no need for a theoretical assertion on password reset. It is equally possible to call it an incident and respond to it or to call it a request and respond to it. you just design your processes accordingly, achieving the best control and smoothness whichever way you choose. If there is a high frequency compared to other incidents/requests then you do, of course, have to take account of where you have placed it when analysing and reporting on statistics.

If it is frequent, is this because

• your users are not well trained?
  your algorithms are very complex?
  your users are many but their use of the systems is infrequent?

Is there something that you can do about any of these - or is just the nature of the beast? - you have to decide.

But what if you provide a fully automated password reset facility? Then perhaps it is just an available service. But do you still need to gather data and does it now lie in the domain of application service management rather than incident or request management?

The exception is where some action within your system has changed user passwords without notifying them but without the intention of barring them from the service. That would be an incident and Change Management would probably want to know about it as well.

[smehdi]

Hi All,

I think the difference between an Incident and a service request lies in the world "NEW"

Requesting for any new service which user never had will fall under service request (It will also include any further modification to this service).

If I take an example of Password reset. The very second and so on........request to reset the password from the user shall be treated as an Incident.

[nisarg]

I cannot really agree to the conflict in defination of Incident and Service Request .
Taking the eaxmple of password reset.Underlying cause for password reset is the lack of users memory and I dont think IT can be blamed of users memory and so no way can a pwd reset be an Incident

So a user forgetting a password is definately a service request by an user and not a fault of IT that it cannot provide the agreed availibilty or capaicity of that particular application.

[smehdi]

Hi Nisarg,

I totally agree with you. The blame goes to user , if he forgets password .

But there are few situations , where user remembers his password but the password gets expired or disabled for some reason .Which in turn is impacting user normal operations.Can this be considered under a service request.

[Marcel]

A lot of good things have been said in this discussion to help distinguish incidents from service requests. That includes the fact that it is ultimately your own organization that determines whether for instance a password reset is an incident or a service request. In most other cases the distinction is crystal clear.

When reading some questions in this thread and especially the following quote, I realized some people do not have a fundamental understanding of the difference between a service, a process, and a function.

A service request aka an incident could be about fixing something which is broken and a new service request is about providing something which was never there.

I hope the following example will make clear what the difference is between those three concepts, which will then give a much better understanding of incident versus service request.

WebMagic is a (fictive) company that hosts websites for their customers. They take care of all the infrastructure and software needed to provide the service of 'web hosting'. They offer several flavors of this service, for instance with different amounts of storage: 1GB, 10GB, and 100GB. As their customer I am not interested in their infrastructure. The only thing that matters to me is that my website is available and performs well in accordance with the service levels agreed upon between me and WebMagic. To support the service they provide WebMagic has a number of internal processes in place to help ensure they can provide the service their customers are paying for. Examples of processes are Change Management and Incident Management. They also have a part of their organization that handles a wide variety of customer contacts, the Service Desk, which is a function. If my website is unavailable, I can call this Service Desk to let them know and tell them to fix the darn thing as quickly as possible. In this situation I am not asking them to provide me a service; I am telling them to restore a service I am already paying for. On another occasion I might be calling the Service Desk and ask them to upgrade my 1GB website to a 10GB website. In this case I am asking for a different service for which I will have to pay extra.

It should be clear from these examples that the Service Desk function is not a service provided to me. It is the function that facilitates communication about services between the provider and the customer. The Service Desk function ties directly into the Incident Management and Request Fullfilment processes that span across the provider's organization. Incident Management helps support the services that the customers are already paying for. Request Fulfillment sets up new services for customers that have been selected from a predefined offering, the Service Catalog.

If you understand the principles of function, process, and service, then you should be able to make a good distinction between incident and service request.