Recently I read an interesting comment about calls and incidents: "From time to time, a consultant is in the position of explaining and justifying fundamentals. Recently I was describing how incidents are not the same thing as calls, that every call is not a new incident if the same user has already called about the same incident previously, that it is more effective to record the call history on the same incident. I went to three sources of "best practice" for support - there isn't any."
Well, well, well… this is what happens when mixing concepts and vocabulary.
First ITIL v3, makes it clear: all calls to the Service Desk are not incidents, service requests and RFC (Request For Changes) have their own process and do no longer follow the incident management route.
This being said, a server is down and you receive 20 calls. Which user will you ask to confirm that the service is restored? only one? the first one? all the users? all those who have complained? And what if the service is partially restored, operational for some but not for everybody? how do you know for sure all users are experiencing the same problem?
At this point, we are not talking about technology any more but communication.
There are different approaches and since there is no real common ground for ITIL, COBIT and ISO/CEI 2000, vendors choose to handle this "their way".
You'll see ITIL solutions where all SD calls reporting an incident are creating a ticket that will be related to a master incident.
You'll see solutions where you have no choice but to create one incident per call (if you want/need to log everything and handle resolution notification properly) without this "inheritance" concept.
As I always say, common sense should always supersede ITIL best practices.
Use your first callers to confirm the restoration of the service and the incident closure. Send all callers (or all users in certain cases) a notification about the incident and its resolution. Anyone who disagree can then reopen the incident, or open another one.
Posts
