Is it a Call? Is it a Service Request? Is it an Incident?

[SD]

Could someone clarify what ITIL says regarding contacts to a Service Desk? We currently classify the initial contact from our customers as Incidents (which means the SLA clock starts ticking).

However, we believe ITIL states that the lifecycle of an 'issue' should start as a Service Request.

Does anyone have any further information on this?

Thanks !

[rjp]

The service request procedure is 'inside' the ITIL incident life as an alternative path to the 'Investigation and Diagnosis' and 'Resolution and Recovery' steps - after 'Initial Classification and Support'

So if there is a 'parent-child' relationship then the parent is the Incident, and the special case child is the 'Service Request'.

Which would indicate that sarting a call as an incident is more 'ITIL' than starting them as 'Service Requests'.

Of course resolving someone's 'issues' is, in common speach, is providing a 'service'. (It's all Serivce after all - and so the term has a lot of nuances throughout ITIL.) But in the Incident Management process 'Service Request' has a specific meaning - "every incident not being a failure in the infrastructure".

This (odd) arrangement of definitions (along with the definition and handling of 'general queries') causes a fair ammount of debate in the ITIL community - some of it can be found in postings on this forum.

Generally Incident Management calls to the Service Desk are handled a little more pragmatically.

In many cases (and quite a few of the major toolset offerings reflect this) a call is initially handled as a 'call', or a 'request' with no ITIL incident 'types' being applied until after the client is identified and an initial summary of the client's concern taken.

At that point enough information has been gathered and the analyst can select the appropriate path - which in the majority of implementations is something like:

Incident - the client's report indicates a disruption that needs to be investigated further, or is the result of a known error.

Service Request - the client want's a known 'deliverable' which will be provided by a known process. (Not strictly what ITIL says, but this approach seems to work quite well).

The general query is a somewhat more vexed issue: Some sites run this as a 'third' type of call, and requests for information are handled specifically as such.

Other site (more ITIL-ishly) handle requests for information which require investigation, and the lack of which is causing a service disruption (even if it's a PBKAC incident - Problem Between Chair and Keyboard ). While a request for information that is expected and deliverabel in a pre-defined format/package may be handled as a service request. There is more variation on how general queries are handled than on almost any other aspect of the IM process. I say whatever works, and lines up correctly with your SLAs.

One advantage of starting with a simple 'call' is that you can handle logging 'junk calls' - wrong numbers for example, and abandoned calls - which are valid for Service Desk metrics, but not for Incident Management metrics.

As for the clock, it can be started with the call - but measurement against the right SLA thresholds will 'start' once the top level classification is made. You are unlikely to want the same thresholds on incident resolution, and service delivery procedures, even for the same service.

[Jon]

Don't know if this helps we separate our requests from incidents at the initial investigation stage. From here it is determined if the call is an incident (any event which is not part of the standard operation of a service.....) or a request for something. The 2 types of calls then follow different processes. Incident follows the incident management process and as an off shoot the request follows the request process. This process could be documented and advertised to users in a Service Catalogue.

[OOSLVR]

It is my understanding and experience that Incidents are only for service outages (something that was working is now broken).
Examples of Incidents are: "The network is down", "our phones are not working", "My monitor died", etc.

Service Requests are submitted for something that did not exist before, such as "Create new network logon", "Provide or Install new application", "Replace my monitor with a 17" flat panel", "Purchase Laptop".

[darkstar]

The definition we use between Incident and Service Request is a "deviation which prevents normal operation" of a service or technology. A Service Request is effecitivly a request for new work or access to a system. Ie being unable to access your system due to your account being locked out would be an incident. A new account for access to a system which you have not had access to before would be a service request.

Unfortunatley our service desk is having severe issues making this distinction which prevents my problem team from accuratley trending what are incident trends and what are service request trends.

[victory]

I believe ITIL doesnt dictate to start the call as "Service Request" .

Service Request is inside the Incident Management and there should be some level of automation for Service Requests like a intranet site where end users can fetch their information themself.

Then it is easy for the Service Desk to start with Incident. We are implementing ITIL with the flow to start with Incident.

Thanks

[ITILImplementer]

We are currently going through this discussion in our organization. My thoughts are below. This is especially important for us because our tool requires each "case" to be classified as one of four case types: Incident, Question, Request and Problem.

Incident-Any degradation or disruption of an existing service. Ends when a known error is identified and known resolution is implemented OR a workaround is identified and implemented.

Request-Any request for the addition (subscription to), modification (change in level of service), or deletion (suspension/cancellation of existing service).

Question-Any request for information to include "How do I's.

Problem-Any issue requiring root cause analysis where a known error does not already exist.

I understand ITIL is a "guide" but am looking for opinions on my definitions. Not so much do they agree with yours but are there any "holes" in them that could create confusion with their use.

[ITILImplementer]

Thanks to those that have replied to my original post below.

Let's give an example:

A user calls because they cannot access their email client. The service desk opens an incident and provides a workaround (granting access to web email). The customer is back in business (can use the email service) and the incident is closed. However to repair the client email, a technician must visit the workstation and provide an id file. How is the second activity recorded? The original SLA was met with the workaround but the customer still needs their client email repaired.

Thoughts?

[BryanRygiel]

[MCroon]

[ChipPanFat]

Normally incidents, problems and changes have different processes behind them although they are related. One incident process may have two related problem processes that are related to it and require 3 change processes to resolve the incident. The incident can be marked as closed if the raise person is satisfied, however the problem and change processes should not be closed until they have been completed.

New service requests or procurement requests will follow a different process and a different method of creating these requests such as email/web rather than calling the ServiceDesk should be made available to your customers as you may wish to keep the lines open for high priority calls.

There should be a facility to change the process/category of an incident in case this needs to be recategorised after further investigation. Its always a problem that a call is logged as a incident and later this needs to be recategorised to maybe a question or procurement request and a different SLA needs to be applied.

[PSuba]