What ITIL V3 says about the distinction between a Call and an Incident
A hundred users call up and say they can't get emails. One incident or 100?
Fundamental and simple question. Go check ITIL for the answer. I'll wait.
You back? What did you find? Got it clear in your head? Great: if you can see the poll to the right of this, choose your answer. (or you can find the poll here)
I got involved in a fascinating discussion over on the itSMFI forum.
One generally accepted practice is to log 100 incidents and have a Master Incident to which the others are linked, though that does not appear in ITIL V3.
The model put forward by Robert Falkowitz and Diarmid in the forum thread is to log the calls but to create only one incident because there has been only one interruption to service. I like the model. The concept of a single incident for many users is a nice one, but I don't think you can say it is a universally accepted one.
Maybe a call should be a separate entity from an incident. But in ITIL V3 it is not. Service Operation says an incoming call is either categorised as an incident or a request (e.g. 6.2.2). Actually it doesn't say very clearly - it is vague about many important things. The fact that the book cannot be used to unambiguously answer a question as fundamental as this reflects badly on it. (The book doesn't say how best to record a followup call for an open incident either).
ITIL V3 certainly does not recognise any entity called a Call or a Contact distinct from an Incident and nowhere does it talk about associating a Call with an Incident let alone linking multiple Calls with a single Incident. Nowhere does it mention logging a Call then attempting to match the Call to a known Incident. (So some products that have been certified by OGC as Incident-process-compliant will not have a distinct Call entity record in them or they will require the Incident record to be created first and then the Call associated with it.) And ITIL only talks about an Incident as being associated with a single user.
As I say, I like the model. It would be great if it was in ITIL so we could all settle on it. What ITIL V3 says about the distinction between a Call and an Incident? Sod all.
It is not an easy question. Are we to have a separate entity called a Contact or Call? If so, do we need to record a call and then create a Service Request associated with it, or is the request a category of call? If it is a category, then what category do we call the calls that relate to an incident? Maybe the category of call is called an Incident, and the new entity we are introducing that isn't in ITIL should be an Interruption? That would make more sense and it would help resolve the confusion introduced by ITIL V3 deciding that an Incident is not just an interruption to service but also a potential interruption to service.
If we had an Interruption entity then that would make service level reporting much easier wouldn't it?
Why is it that twenty years into ITIL's history we are still debating this stuff and the book holds no unambiguous answers as to what is best practice in ITIL's core heartland process?
Of course if they had made a call [pun intended] one way or the other and defined how it is best done, they would have upset some powerful vendors whose products don't work that way. Perish the thought that vendors had any influence over the content of V3. I'm sure it is just that they didn't think it through or that they just thought it is not important. I'm sure it is not intentionally vague: that wouldn't be in the best interests of the purchasers of ITIL.
Made in New Zealand 
Comments
Descriptive not proscriptive
Maybe I'm missing something -- again. :-) What's the real issue here?
Isn't ITIL descriptive -- or supposed to be? It's guidance not "the holy writ" -- which means there's room for interpretation.
If ITIL was supposed to be proscriptive (a la PMBOK or PRINCE2) I'd agree with the questions raised.
Something I said on Twitter I believe to be relevant here: ITIL confused leads to dogma, ITIL understood leads to ITSM.
In other words, it's a matter of what works. An incident is the unplanned interruption or degradation in quality of...
Multiple calls about the same interruption or same quality issues doesn't make each individual call an incident. Whether or not the organization does or doesn't categorize is less important than addressing the overall goal of Incident Management: do something to restore service as rapidly as possible. I thought it was about... that the end result real goal was IT service management.
Every incident (not call, incident) should have a review before the ticket is closed. The purpose for the review is to get the right categorization, etc. In other words, there's the specific incident goal (restore service quickly) and the overarching process goal that includes learning and improving.
What did we do right?
What did we do wrong?
What can be done better?
How do we keep this from happening again?
What type of (and when is) follow-up required?
Given the discussion it's clear that I don't understand something -- and I'm not sure what it is? Someone please tell me what I've missed.
Thank you.
David
what guidance does HDI give on this?
Whether ITIL is descriptive or prescriptive, it purports to DESCRIBE best practice. To what purpose? if it is to describe abstract principles that are to be interpreted by expensive priests ...er... consultants, then much of the detail in ITIL would seem to restrict the creative genius of those stellar persons.
On the other hand if it is to DESCRIBE what best ITSM looks like for those not blessed with a prior in-depth knowledge of ITSM, then I'd say how BEST to handle and categorise incoming calls to a service desk was a pretty fadurkin' fundamental omission.
You folk in HDI, what guidance does HDI give on this?
Master Incident beats Problem to a pulp
Problem is feeling very sad and lonely, because Master Incident has come in and taken over his turf, without so much as a fair fight.
Problem has lost the right to own any situation that involves "multiple related incidents" and has been relegated to the annals of history.
Having beaten Problem to a pulp, Master Incident is now eyeing up Major Incident's territory. However, IT Service Continuity and Service Recovery have Major Incident's back, providing Master Incident with a real fight.
Will Problem see its nemesis fall, and rise to power as the keeper of the truth, aka "root cause analysis"?
Stay tuned, for iTIL V4, coming soon to a 3rd party supplier near you!
When do you assign call to incident
If a call is not an incident, when and why do you assign it to an incident? Are you short-cutting the evaluation of the incident by creating a new process ?
If the customer says "my email is not working" then by attaching it to an incident, you assume that the same cause is the result of the symptom.
Test Scenario: If the email is down due to a major networking failure (which you do not know yet) in one division in the company and 100 users are affected, and another customer rings in with "my email is not working" and the cause is finger trouble on a password, or they forgot to plug the network cable into the back of the machine. The 101 customer waits until the network falure is fixed, and then finds out they need to plug in the cable.
If you create a call or contact label, are you then saying to connect the call/contact to an existing incident as a shortcut instead of running through the predefined analysis flow to find a work-around which includes assessing against all the know workarounds for that symptom type.
So when is this shortcut analysis flow effective. Is it the 10th common symptom call or the 100th ?
$0.02
Brad Vaughan
jump to conclusions
I agree, but I think the danger is in how one approaches each call, not in the model. For example in the scenario you describe (same one I and also David Cannon :D described in that forum thread) it is just as easy to jump to conclusions when each call is an incident, and automatically link the incident to a Master Incident assuming same root cause.
So whats the upside
So whats the upside of a call/contact label ?
Or are you going to make me read the forum ?
Brad Vaughan
pros and cons
Not sure. there are pros and cons.
Whatever you call it and wherever you put it, there is a missing entity. there needs to be two entities: the service outage (one per outage) and the user impact (one per user). Which ever one is labelled Incident, there needs to be the other. ITIL doesn't say which and never talks about the need for both.
What gets my attention is that after twenty years no-one has weighed the pros and cons and documented the best practice, least of all in ITIL
What about Events?
I was reading through your post and then went back to the book to read more. Here is what it says
From my experience with two organizations here is how they modelled
1. First contact is a call. A call can be an incident, a service request or How-To question. Calls are to be handled by the Service Desk and most how-to should have a first contact resolution and so on... multiple calls does not necessarily mean multiple incidents.. if they are for the same issue, One incident should be attached to multiple calls and the priority/urgency/severity increased for that incident. The tool in this case was Tivoli CSD
2. First contact is a Service Management Ticket... it would become an incident ticket only if it qualifies as an incident! so SM tickets to IM Tickets and IM tickets would usually be less than SM tickets. Tool used here is the HPSC
implication
Sorry Prashant but I don' think that has advanced our discussion any. Both instances are a case of introducing the Call entity in front of the Incident entity.
Incidentally [pun int.] that extract is one of many that implies (or certainly can be interpreted that) there is NOT any additional Call entity in front of Incident: Incident Management includes ...events which are communicated directly by users... Incidents can also be reported and/or logged by...
Event, call, Incident and request
Pardon me, I am a bit confused on the focus of this debate:
Is it 'what should be the better way to handle such scenarios' or 'Is ITIL having a clear guidance on that?
It is not really clear on the best practice (er..Good Practice) documentation of ITIL.
We have guided a couple of organizations around this question -
though really haven't put such a deep thought into this.
Not much different from what Skeptic and some others have put across:
We start with an Event (detected and handled through event management process) and a call (handled as human reporting at service desk)
Now an event - if it is an interruption (or potential interruption) of a service - gets logged/categorized/tagged as Incident.Other events are handled through different response selection in event management
A call at service desk can be treated in two possible ways:
1. It is logged as a call/ticket (or whatever) - and then categorized/tagged as incident or service request as the case may be.
or
2. It is logged as an incident - and later categorized/tagged as service request (if it not an interruption or potentiona interruption) and passed through request fulfilment process. - the good old V2 structure of Incident management process.
The second option "incidentally" (pun int. again :-) ) removes the need of an entity called call/ticket before Incident.
And to talk about the scenario of master incident, I think linking to the master ticket is the more logical option, with clear criteria for doing so.
Sounds a bit familiar
Your second option reminded me of an organization I helped over ten years ago. Their solution is still very relevant and impressive today. There was no manual categorizing of calls by the Service Desk. It was their opinion, and is still mine, that we want the support staff to be focused on the solution, not taking time to put the call in its proper bucket. Let the solution define the problem. The service support team simply asked a series of questions (read mostly from the screen) and recorded the user’s response. After some time, nearly 95% of all calls went according to script. The problems users faced were recorded as well as a host of data about the call, staff response, workarounds, etc. We also had a list of workarounds with no solutions and a few with no work around which were immediately escalated. If we wanted to investigate calls about a particular application outage we simply looked at that date or applications history. The system had its problems but by in large I'm still waiting form some of the big vendors to catch up. And it still pains me when I hear first tier staff ask which category they need to put a particular call in - it is a waste of their time and far too subjective.
let the solution define the category
P.Menafee, your "let the solution define the category" (which bis what I'm sure you meant :D) approach is sensible. It is a fresh way of looking at what I have advocated: there is only one entity, a Response, which we categorise as we go along, and only one process for dealing with them - with variants.
Yes, focus on solution
There you go, I could not put that in so short and sweet way: " Let the solution define the problem" - Exactly what I used to think and I would put that as " let the solution define category/ticket type" Ultimately the user want a 'solution' to their need (for support).
Thanks
Vinod Agrasala
www.itserviceview.com
I agree that ITIL does not have that distinction
and was just putting across a way that I have seen this distinction being handled!
Outage
When I got my ITIL cert we commonly logged each call reporting an outage as an incident (Unicenter Service Desk, as we use it does not manage "calls" per se) and collect all of the incident tickets under a "problem" ticket and that problem ticket is managed by both the problem management group and the department responsible for resolving the outage. All of this is pretty straightforward in my organization.
Would you like a problem with your incident?
Doing your incident correlation in problem is really a workaround because the tool is a bad fit for existing process. I've also seen this when the service desk doesn't do any serious incident correlation and blindly pushes tickets to backline teams where the correlation occurs. If it works, keep it up. However, I have to wonder how a mature problem landscape is naviagted when the waters are muddied by incidents.
Even if...
Even if ITIL doesn't tell you which way to go, do the "certified" tools? IF you find an ITSM tool that allows you to log calls (not all do), is that an extra step for every incident? What if you only have one call? Mirror this with the "internal assignment" feature of some tools. Do you create an assignment if it is a first call resolution? I don't look to ITIL or MOF to answer all of this. I simply wanted to echo the point that the tools are equally undecided.
one current generation ITSM
one current generation ITSM automation suite [ed: name removed] includes the concept of an interaction (to log the calls) with the ability to 'escalate' to incident, which can also we tagged to a master incident. Kinda complex but makes for complex reporting
[ed: several do this but not all]