Differentiate between Incident and normal help desk call

[lastofthebreed]

Hi

I need to know How to differentiate between an incident (as in incident management process) and an normal user complaint (user call as defined in help desk)

We have a help desk system through which users log their complaints if any. The help desk tries to solve the same using the help of a knowledge base. In case it cannot solve the same , it is escalated to next level supports (a tech support guys, Database and OS guys, Security guys etc)
We also have SLA s defined for the same.

Now while consiodering ITIL best practices, I am in dilemma as to which calls are going to be considered as incidents (handled seperately) and which would be normal calls?

Regards

Chetak

[Conexio]

Every call is an incident. there is no such thing as a normal call to the service desk. You can differentiate between types of incidents, but they should all be treated as incidents.



[Editors note: Promotional text edited out]

[Guest]

dONT GET HUNG UP ON WHATS AN INCIDENT WHATS A COMPLAINT.
AS ALREADY SAID THEY ARE ALL INCIDENTS.
HELPLINE STAFF SHOULD HAVE GUIDELINES TO PROIORITISE EACH CALL
ON ITS MERITS.
SOME WILL BE KNOWN ERRORS AND HELDESK STAFF WILL FIX THEM THERE AND THEM.
SOME WILL NEED FURTHER INVESTIGATION BY SUPPORT STAFF.
SOME HIGH IMPACT MAY NEED TO BE ESCALLATED.
PROBLEM MANAGEMENT SHOULD CATEGORISE THESE INCIDENTS AND WHERE APPROPRIATE ORDER FURTHER INVESTIGATION TO EITHER PUT IN A LONG TERM FIX OR STICK WITH THE WORKAROUND.

[faznjaz]

TaxonomyTriage is essential. I agree all calls to the service desk should be considered an incident, however not all calls need to go through the 'incident management lifecycle'. If someone calls the SD in need of directions to headquarters obviously this is not an interruption of service that needs to be disagnosed, restored etc. However, the call should be recorded as an incident as some classification such as misc. These calls, although they may be quick to close, they do impact the workload/volume of the SD. If the SD manager or problem management run some trend analysis on these miscellaneous calls it may identify a 'problem' that can be addressed to relieve the SD, enabling them to deal more efficiently with those incidents that need the full IM lifecycle.

[rhowald]

This is an excellent point... Actually you could use 3 top level qualifiers for calls...

HOWTO - Basic questions on useability or process questions.

Request for Service - Move/Add/Change, Service enhancement.

Breakfix/Incident - This type of call would be classified as an Incident.

When you get down to this level, this is where ITIL needs to be interpreted by your Process Leads and some common sense injected into it.

Discussion???

Robert

[rhowald]

Before people start correcting... I realize that ITIL does state that a Service Request is an Incident... However, this does not always fit into the definition of an Incident:

"An Incident is 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".

I prefer to keep Service Requests seperate from Incidents because they would have their own standardized processes.

However like everything as we implement ITIL it is something that will need to be discussed as we create/modernize our processes to align with the ITIL Service Management framework.

Now that I have clarified, please feel free to open thoughtful discussion on the topic.



Robert

[Gav]

I think we all agree here. A simple solution is to have a status type in your tool as 'service request'. This could be reserved for incidents of a non-technical nature, or whatever suits your service desk. (eg. a light bulb needs fixing).

Faznjaz makes an important point, that all calls impact the service desks workload and need to be recorded. Whether they be about a light bulb that needs replacing or a server crashing.

[blamblam]

Yes. Not all calls to the Service Desk will be Incidents. Most Service Desks I have worked with take a wide variety of calls. A recent one is an exmaple:

The Service Desk worked from to major forms - Service Desk and Change Management.

The Service Desk form logged the following call types:

Incident - self explanatory
Problem - self explanatory
Request - general requests for assistance
Question - how do I? where do I?

Requests and Questions were split out as there was a need to identify potential training issues.

The Change Management form logged all Requests for Change including MACs. These were later redefined as Non-standard and Standard Changes so the drop down showed:

Standard
Minor (Non-standard)
Significant (Non-standard)
Major (Non-standard)
Urgent (Non-standard)

All standard changes had approval delegated to the Service Desk.

But ALL calls to the Service Desk either resulted in a new entry or an update to an existing entry in the database!

[JB]

[blamblam]

[rjp]

Wow, this is obviously a 'hot issue' question....so my 2 cents worth is;

There is a lot of discussion about the 'Service Request' vs 'Incident Report' vs 'General Query' classification.
To say they are all incidents is counter-intuitive, especially given that 'Incident Report' is both the primary class and a variation of it.

I think the ITIL authors saw it this way because the focus is on the business. If a capability in the business is adversely affected - in any way - by IT, then it is an incident. Now a business activity may stop or slow down because someone out there doesn't have an email account. Nothing 'broke' or 'failed', but that doesn't matter in theory because there is still a disruption. The same can be said of a end-user in the business who doesn't know how to do something they need to.

Because of this they all share certain things in common: They are all (at one time or another) client-initiated processes (Hence the need for the Incident Detection step in the Incident Life Cycle. They should all be carried out with defined targets in mind, and should all have functional and hierarchical escalation points defined to cope with delivery problems. In each case there is a point where the business capability is returned to its normal state.

Of course there are differences too: The key difference being that between activity where the process is completely pre-defined: Known inputs, known activity and resources, and a known outcome. Service Requests should look like this all the time. But, bear in mind, that once a frequently occurring incident has been resolved the first time, or a root cause analysis has been done by problem management, known steps to identify that incident (known inputs), and known steps to apply a work around or resolution (know activity and resources) and a known outcome also exist - in which case an incident begins to look, from a process point of view, very much like a service request procedure.

A key to resolving the call classification issue that I advocate is to use your Services as the organizing principle for all requests - ie, don't classify incidents against technology (hard and soft) while classifying service requests against services and queries against whatever...
Classify everything according to the same schema of Services, and allow for the different types of request.

Also bear in mind there will have to be a business number/email/address for the service desk staff that is not for the service desk. (What if someone in personnel wants to discuss something specific with one of the Service Desk staff? - They will need a way to contact that person that isn't an 'IT Call Centre' number) Make sure there is a separate official Service Desk number, but remember some numbers will be wrong-numbers and so on, if you require a record for every pick-up make sure there is a way to record 'junk calls'.

Customer satisfaction recording is separate task to incident management. The Service Desk should definitely have a mechanism dedicated to the immediate capture of customer satisfaction information - so if a customer complains, or says 'why don't you do xxxxxx? then the complaint or suggestion can be captured without being shoe-horned into your incident management processes.

Related to this is the issue of what constitutes an incident; Is a failure by IT to carry out a service request procedure in an agreed time frame an incident? Should you log a separate incident report if a service request delivery fails? For the sake of sanity, I think it would be wise not to get into some kind if ITSM infinite loop: Incident Management is not a Service, it is what you do to ensure good service delivery. A problem anywhere in the Incident Management process is not another incident - it needs to be dealt with as a part of processes dedicated to monitoring your performance and developing your Continuous Improvement Plan.