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.

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.

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)

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.

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

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).

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)

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

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.....

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.