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
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 logging an incident for every call necessary?
Posted: Mon Mar 31, 2008 11:35 pm Post subject: Is logging an incident for every call necessary?
Hi All,
I have always pushed our service desk to log an incident for every call they take as I remember this being repeatedly mentioned in my Service Desk practitioners course...however...i am struggling to remember the benefits / argument for doing so.
When we have a priority one incident, we can take a heck of alot of calls for the same issue. What our service desk team leader is saying is that he doesnt want the service desk logging a new incident for each call as it is counter productive. he wants them to update the initial incident everytime they take a call for it.
Joined: Aug 11, 2006 Posts: 262 Location: Netherlands
Posted: Tue Apr 01, 2008 12:19 am Post subject:
Benson,
First of all: ITIL is descriptive, not prescriptive.
The benefit of an incident per call is the insight it gives in workload. Also, it makes a caller identifiable for feedback and reporting the incident solved. As long as the update to the existing incident is done in a reportable (reproducable) way, it still gives you the management insight. Some tools do provide an option for easy copying of existing incidents.
Joined: Sep 16, 2006 Posts: 3110 Location: London, UK
Posted: Tue Apr 01, 2008 12:41 am Post subject:
As M_croon has said
how can you tell the volume and imapct of the change
if there is a major incident and i am affected and I call the SD to report the issue, I WANT a incident number
otherwise how do I know that i am included in the stats for the major incident
NOTE: Most tools have the ability to duplicate a ticket
As I have managed a SD, I would have the major ticket running - with updates on how many individuals called, name, time of call, give them the major - recorded in the major ticket. As I would be running the escalation on the major incident, I could do the individuals if he policy is to tdo so _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Joined: Jan 03, 2007 Posts: 189 Location: Redmond, WA
Posted: Tue Apr 01, 2008 5:15 am Post subject:
Another aspect to consider is that Problem Management uses the Incident database to route out procedural faults in the Service Management processes. For them to discover that the user's don't feel they are being serviced in a timely fashion, there has to be a separate Incident record for each call.
When I worked in a Service Desk, we had our analysts log a new Incident record that the user had called back on Incident #xxxx and resolve that record (we had a fairly automated way of logging this type ticket and it took very few keystrokes). After the new Incident was logged, the analyst would open the existing Incident that needed to be updated and add a new entry in the audit log for the the update.
Joined: Mar 04, 2008 Posts: 1883 Location: Newcastle-under-Lyme
Posted: Tue Apr 01, 2008 8:35 am Post subject:
Hi,
To have a proper understanding of how your services are behaving, you have to distinguish between multiple calls for the same incident and multiple occurrences of the same incident.
It is real events that are of interest. There is a world of difference between how many times something has occurred and how many people have reported it ("we had a thousand server incidents yesterday" or " "we got a thousand calls when the server failed").
- you need to know how many calls you receive (to measure the workload on the call centre/service desk)
- you need to know how many incidents occur (for problem, availability, SLA etc.)
- you need to know who is affected by in incident (so that you can communicate with them)
So your call logging functionality needs to provide the capability of this analysis along with everything else. Service improvement depends on good information. _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
To have a proper understanding of how your services are behaving, you have to distinguish between multiple calls for the same incident and multiple occurrences of the same incident.
I wish this forum had a means of giving reps. The quoted text deserves repeating. Matter of fact, it deserves tatooing!
Joined: Dec 30, 2005 Posts: 21 Location: Navi Mumbai, Maharashtra, India
Posted: Thu Apr 24, 2008 9:22 pm Post subject: One incidnt for each incomming call? No No!
Hi,
Creating one incident record for each incoming call is unfair and misguiding. Also the discussion looks like due to confusion between terms "Incident" (the actual disturbance to Service) and "Incident Record" (information recorded in a tool, well known as tickets). Incident by definition is a service disruption and not the record created to register the disruption.
You must create a record of each incoming call for analyzing load on CC/SD and communication of incident resolution. When you are sure that the incoming call is referring to already recorded incident, you simply "Link" the call to incident record. Today some tools support concept of parent and child incident records (tickets). While analyzing number of service affecting incidents or total down time, you need to count only parent records which, is a true way of counting service disruptions. These tools also support auto-closing of child incident records and auto-communication when the parent incident is closed.
When moving to Problem management, if you are counting number of repeated incidents to analyze and create a problem record, the number will be misguiding if the multiple incident records are created for one incident. To do trend analysis of incidents, you need to filter only the parent incident records (or ticket).
Joined: Sep 16, 2006 Posts: 3110 Location: London, UK
Posted: Thu Apr 24, 2008 9:50 pm Post subject:
Mredaker,
We are talking about both. The incident record (ticket ) is the way IT tracks the number of incidents that are happening.
As to opening a ticket for each call, how is the SD and the incident mgmt suppose to know how many users have contacted the SD to complain about an incident
it does not bode well if the SD says, we only create 1 ticket and told the rest of the users to piss off because we already have aticket for this
how is the count of the # of users going to be tracked
When mgmt asks.. well how many people called about this incident
And the SD goes - well, ... i dont know. there were multiple calls but we did not track them or who they were.
SD mgmt will look like and rightly so incompetant **s***es
If I were senior mgmt, I would replace the SD mgmt most hastily as they are not doing their job
Incidents can and do occur whether the user/customer contacts the service desk or not
however, the impact of the incident and the true valuation of an incident does not occur unless some user complains about it
Therefore, if I call the service desk with an issue about the service I am suppose to be able to use and the service desk does not wish to open a ticket for any reason, then my next call will be to the management who made that decision
the logging of the call is the only way to determine whether activity on the it environment has any impact o _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Joined: Sep 16, 2006 Posts: 3110 Location: London, UK
Posted: Thu Apr 24, 2008 9:56 pm Post subject:
Mredekar,
This is the Service Desk forum.
In order for the SD to track the # of calls that are handled by the SD STaff, the calls have to be recorded somewhere.
If the user is calling about an issue from their point of view, then the recorded ticket is for an incident
The need to record all calls in the system is the only way to gauge how busy a SD is, how lmany people are impacted by an uncident or not, etc etc
I still advocate that all calls need to be logged. How is it done is immaterial. _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
I agree with the 'Staff' above, but let's also strip away IT processes and best practice etc. for a minute and go back to the very basics: How else do you justify having the SD in the first place?
Every call has an impact on your SD as a service in terms of resourcing and availability.
Cheers,
UJ
(And May the fourth be with you... dammit that's still a couple of weeks away. I will be back with that appauling pun, mark my words!!) _________________ Did I just say that out loud?
Joined: Mar 04, 2008 Posts: 1883 Location: Newcastle-under-Lyme
Posted: Sat Apr 26, 2008 5:51 pm Post subject:
Hi,
I'd like to say I agree as well, but I have not a clue what Ukviking's two posts are about. Mredekar seemed to me to cover all the bases. Perhaps it's just that different software is involved and so the terminology and the practicalities are affected. _________________ "Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Joined: Sep 16, 2006 Posts: 3110 Location: London, UK
Posted: Tue Apr 29, 2008 6:31 pm Post subject:
You know, I read my posts and even I dont know what I was saying
giggle.
I think the issue I had with Mredekar was the assumption that incidents tickets should not be raised for every call.
I think like UJ put.. Log everything.....
I think I was trying to say that the existance of the Service Desk is dependant on the # of people that call to complain, request etc about the IT service
If there is no calls to the SD,then why have the SD ? would be one question mgmt might ask
As to the explicit logging of a call, well... most ACD systems can track the number of calls, dropped calls, etc average wait time...etc
If a person calls the SD and asks what the weather is .. I would politely tell him / her is frigging cold in hell. (or something similar)
if the person does it every day (asking the SD for some thing that they can do), I would raise tickets and get him official notice. for stupidity
The other issue is that if an call is about an actual ITIL defined incident and there is already a ticket open, the next call(s) should have a ticket as well - part to identify who has been affected and how broad the incident is impacted by the incident
the SD team leader or mgr sohould be looking for things like mutliple tickets for thesame incident..... this is a good hint for a MAJOR incident.....
nuff said thisweek _________________ John Hardesty
ITSM Manager's Certificate (Red Badge)
Change Management is POWER & CONTROL. /....evil laughter
Joined: Dec 30, 2005 Posts: 21 Location: Navi Mumbai, Maharashtra, India
Posted: Tue Apr 29, 2008 6:49 pm Post subject:
Hello UKViking,
Greetings!!
I totally agree with logging a ticket for every incoming call (my earlier post also mentions that). This is must for analyzing the load we have on SD team and for many other reasons. All I am trying to say is that all later created tickets can be linked to a parent ticket (the first ticket created for the incident), so that end of the day we say one incident took place today instead of saying forty incidents took place today, just because forty users called up for same incident or same service unavailability.
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
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
