Free Downloads

MindMaps:
ISO 20000: 2011
and
ITIL 2011 MMap
 

Templates:
Request for Change (RFC) Template

Major Incident Report Template

Posters:
ISO 20000/ITIL Timeline poster

    

Sponsored Links

 

Google

May 10, 2010

Many Calls One Incident

Every time user calls in, we log it as the new incident. Or we update an existing incident.
What happens when one major business service goes down? Do we log every call from a different user as a new incident?
Are these just related incidents or there is only one incident? What are calls?

I have seen a few interesting discussions on the Net about the technology of Service Desk Incident logging.

Since I have some 18 years of IT Service Management experience in practice and in theory, and this is a matter I have a strong opinion about, I might say a few words about it.

INCIDENT MANAGEMENT PROCESS
Incident Management is the oldest and most chewed up process in all IT Service Management. Everyone does Incident Management. Maybe not Capacity Management or IT Financial Management, but Incident Management is in phase 1 of most ITSM/ITIL implementations. So it is the best defined and best known process. Everyone interested in ITSM knows everything about it. Right?

DEFINITIONS
What was the definition of an incident? Here are some:
  • ITIL V2: any event which is not part of the standard operation of a service and which causes, or may cause, an interruption to, or a reduction in, the quality of that service.
     
  • ITIL V3: An unplanned interruption to an IT service or reduction in the quality of an IT service. Failure of a configuration item that has not yet impacted service is also an incident, for example failure of one disk from a mirror set.
     
  • MOF: Failure of a service or component to provide a feature it was designed to deliver.
Very nice. All bases covered. Very defined. For decades.

SCENARIOS
So consider a few scenarios:
  • User cannot log in, she forgot her password. Service Desk creates a incident ticket and resolves it in a first call. Splendid.
     
  • User has a problem with his PC. Service Desk assigns a technician on that incident . Technician visits the customer, resolves the incident and SD closes it.
     
  • Print server goes down. No one in the headquarters can print. Imagine the legal department people. Sales girls and their Tenders & Invoices... Hell must be a nicer place to be. Phones are off the hook, percentage of unanswered calls goes up fast.
Imagine a mail server crash in a large enterprise. That must be a show. This is a very common case, happens every day in IT all over the world.

So then, is every new call from a panicking user a new incident? Or it is just one incident, and many end user calls (inquiries?). Read ITIL books V2 and V3 all you want and you won't find the answer.

V2 books are in favor of rule that every new call is an incident. OK maybe if the same contact person calls a second time, then it can (maybe) be logged in the same Incident record. But, another person, another Incident.

V3 broke Incident management into new Incident Management and Request Fulfillment with an eye on Event Management. So everything is not an incident any more, it can be an user request. Which doesn't help us here much. Every call about the incident is still an incident by our good ITIL books. And that's best practice. Sort of.

ITIL Service Management sure has some place for improvement here. What I feel sorry for is that authors of V3 strived to cover as much new territory they could (Knowledge Management? Strategy Generation?), creating more ambiguity and material which will need improvement, and flaws of the basic processes remain uncovered. Best practice system should cover such basic scenarios as above mentioned.

What happens in example above, if every call is an incident? All incidents are logged and categorized. A lot of them.

If a mail server went down, is it a new incident every time user notices he can't send mail? No, of course not. It's ONE incident, i.e. one interruption of the mail service. In a good Service Desk environment this incident will often be recorded before any user notices it. The amount of users impacted will only influence Priority of the incident, (remember, Impact X Urgency), not the number of incidents.

This is a nice question I have asked every ITIL trainer/consultant I've met, and I've always had fun.


HOW SHOULD IT BE DONE? 
So, how do you do it at home?

In my company, Service Desk has an Incident Management tool which enables us to log an Incident. All later calls from the same contact person (department) are logged as updates of that incident.

All later calls from new persons regarding that incident (mail server down!) are creating new tickets which are connected to that first incident. These related tickets are not considered incidents, we call them simply "tickets".

When the original incident is resolved, an original contact person for that incident is asked to confirm. Incident is then closed, and all associated tickets too. All contact persons from these tickets get a notification about the closure and are asked to reopen the incident if they feel their service is not yet restored.

Some tools on the market even have special entities, "Calls", which are linked to an initial Incident in a similar manner. Some other tools are at least able to interlink incidents so that when the original one is resolved, SD people can at resolve related incidents one by one, "on foot".

This scenario can repeat quite often in enterprise Incident Management, even in mid-sized managed service companies. So it would be nice if someone explained it to good ITIL best practices author.

NOTE
There is one potential catch with "One incident/Many tickets" method: if you treat various departments or business units of your company as different customers, i.e. you have a different SLA with Finance, Legal or Marketing, then you would want incidents and outages to show on their respective SLA reports. If your IM and reporting tools are not perfectly linked to the service Configuration Items in your CMDB or your Service Catalog item, you will probably want to create one incident for every contracted SLA.

This will also be the case if your contact defines a business unit associated with the incident, and the reporting tool regards incidents as service disruptions on associated business units. Here the value of a good Service Catalog/Portfolio comes to the fore.

Sometimes this vagueness is justified by “descriptive, non prescriptive” nature of ITIL. Well in my humble opinion, if something is called best practice, then it should describe the best practice of common events.

It would be very nice if this issue gets to be addressed in the next ITIL release, don't you agree?

Related posts:

Incident Management Elements
Key elements of Incident management.
http://itservicemngmt.blogspot.com/2007/05/i-will-go-through-main-elements-of-itsm.html

Incident Management Mind Map
Download the incident management mind map.
http://itservicemngmt.blogspot.com/2007/05/incident-management-mind-map.html

All About Incident Classification
How to deal with incident categories.
 
Incident prioritization in ITIL.
  



7 comments:

Jack said...

This is great stuff! Glad to see a fresh post. Please keep writing! :)

alkin said...

Please keep writing! Great post as ussual, it has been a long time!

doctor said...

Thanks Jack and Alkin,
I have a few posts in mind, they will have to wait for a maintenance window in my work schedule :)

Daniel said...

Excellent stuff.

We are currently evaluating several of the tools you referred to and one of them actually refers to incoming calls as "Interactions" which can then lead to an Incident or a Request, etc.

I'm glad we're not the only one with this issue. :-)

Hammy said...

Great info. Here is how I handle such scenarios:
Most recent versions of ITIL compliant ITSM tools would support Relationships – so does the Remedy 7.5 the company I work at uses. We would create one High-Priority Incident record and link the related calls (as resolved Requests/Inquiries or as resolved medium-priority Call Incidents). The reason for logging the calls is for audit purposes and to maintain perspective of the High-Priority Incident’s Impact. I use this info periodically to revise my Incident Priority model (Impact vs. Urgency) and to progress Problem Investigations.

As for the "One incident/Many tickets" potential catch: We do create several High tickets; one per SLA contract but we make sure that the Relationships feature is used properly.

Jeff said...

OK, so if each call gets federated to the ticket, should the Service Desk not put up a message that they know about the incident to deflect people from continuing to hold and tieing up the lines (and skewing our metrics)? Should we let those calls continue and answer them so the call can be linked to the original ticket?

doctor said...

Jeff, of course if there is a self-help tool or Service Management web site in place, then this should be stated in Announcement or News area.

Also, if you have an IVR system and a Major incident with large volume of calls then you will put an info about it on the beggining of the welcome message...

You might want to have a look at Many Calls One Incident article.

Have a nice day!