Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: KClopton
New Today: 35
New Yesterday: 81
Overall: 143454

People Online:
Visitors: 67
Members: 4
Total: 71 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

Note: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


The Itil Community Forum: Forums

ITIL :: View topic - Is it a Call? Is it a Service Request? Is it an Incident?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

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

 
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion
View previous topic :: View next topic  
Author Message
SD
Newbie
Newbie


Joined: Aug 29, 2005
Posts: 8
Location: Dublin, Ireland

PostPosted: Thu Sep 22, 2005 7:26 pm    Post subject: Is it a Call? Is it a Service Request? Is it an Incident? Reply with quote

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 !
Back to top
View user's profile
rjp
Senior Itiler


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Thu Sep 22, 2005 11:37 pm    Post subject: Reply with quote

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 Wink ). 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.
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
Jon
Newbie
Newbie


Joined: Jun 23, 2005
Posts: 2

PostPosted: Tue Sep 27, 2005 12:45 am    Post subject: Reply with quote

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.
Back to top
View user's profile
OOSLVR
Newbie
Newbie


Joined: Jul 18, 2006
Posts: 2

PostPosted: Wed Jul 19, 2006 10:14 am    Post subject: Reply with quote

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".
Back to top
View user's profile
darkstar
Newbie
Newbie


Joined: Jul 19, 2006
Posts: 5

PostPosted: Thu Jul 20, 2006 1:19 am    Post subject: Reply with quote

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.
Back to top
View user's profile
victory
Newbie
Newbie


Joined: Jul 23, 2006
Posts: 6

PostPosted: Sun Jul 23, 2006 11:04 pm    Post subject: Reply with quote

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
Rolling Eyes
Back to top
View user's profile
ITILImplementer
Newbie
Newbie


Joined: Jul 26, 2006
Posts: 2

PostPosted: Thu Jul 27, 2006 3:10 am    Post subject: My take Reply with quote

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.
Back to top
View user's profile
ITILImplementer
Newbie
Newbie


Joined: Jul 26, 2006
Posts: 2

PostPosted: Fri Jul 28, 2006 6:10 am    Post subject: A scenario for comments Reply with quote

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?
Back to top
View user's profile
BryanRygiel
Newbie
Newbie


Joined: Aug 04, 2006
Posts: 1
Location: NJ

PostPosted: Fri Aug 04, 2006 11:15 pm    Post subject: Re: A scenario for comments Reply with quote

ITILImplementer wrote:
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?


That's a good example. If you follow the Incident Life Cycle, you're already past the Service Request decision, and are moving towards recognition and resolution.

I don't believe the incident should have been closed once service was initially restored. The Service Desk provides the work around, but it is still a problem, then a known error which needs resolution for service restoration.

I agree with what's been mentioned, a service request involves providing a solution where none existed before. Example: Getting a new printer vs trouble with an existing one or installing a software package vs trouble with an existing application.

Bryan
Back to top
View user's profile
MCroon
Newbie
Newbie


Joined: Aug 09, 2006
Posts: 3
Location: Utrecht, Netherlands

PostPosted: Wed Aug 09, 2006 9:59 pm    Post subject: Reply with quote

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


I know that HP's Openview/ServiceDesk has a separate service call module (apart from modules for incident, problem, change and cmdb) which is the only part of their service management tool where you can steer through service levels. Therefore: using HP ServiceDesk you should always start by logging a service call, also when talking about a disruption. This is certainly not ITIL-compliant. Is it possible that your believe is related to this tool?
Back to top
View user's profile
ChipPanFat
Newbie
Newbie


Joined: Aug 31, 2006
Posts: 6
Location: Singapore

PostPosted: Thu Aug 31, 2006 4:05 pm    Post subject: IPC Reply with quote

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.
Back to top
View user's profile Visit poster's website MSN Messenger
PSuba
Newbie
Newbie


Joined: Aug 31, 2006
Posts: 1

PostPosted: Thu Aug 31, 2006 9:25 pm    Post subject: Re: A scenario for comments Reply with quote

BryanRygiel wrote:
ITILImplementer wrote:
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?


That's a good example. If you follow the Incident Life Cycle, you're already past the Service Request decision, and are moving towards recognition and resolution.

I don't believe the incident should have been closed once service was initially restored. The Service Desk provides the work around, but it is still a problem, then a known error which needs resolution for service restoration.



Bryan,

I think it is in a way simpler in a way more complicated.
We have been through this with our field services organization and the conclusion was that it will depend on your SLA.

If within your SLA the service definition says that the "normal operation of the service" is to be able to send and receive mail, independently of the application that is used, in this case the incident can be resolved and the reinstallation of the Outlook client (or whatever) will be classified as Recovery. This has effect of having to meet the SLA.

On the other hand, if the SLA defines the service as as explicit requirement that the email client has to be functioning also, in this case the web mail usage is an action that reduces the business impact (temporary solution), but is not a resolution so the case can not be considered solved.

In both cases the second activity is part of the same incident process flow, and will be (in our case at least) logged in the incident's ticket as an activity log.

Also in our situation the case will be tracked so that the activities can be matched to the SLA and the billing at the same time (i.e. the statuses will be used accordingly and reporting is based on that) For example if the field services activity is separately billed, this will be based off of the incident's track log's reporting. This way the agents who manage the calls are not confused, we do not circumvent the ITIL process in having a single case just for the purposes of billing and use a practical way also.

Peter
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.