The IT Skeptic - Comments for "Are Incident and Complaint different things?"

KISS

Geert — Thu, 11 Jun 2009 11:03:00 +0000

In my company we've setup our service desk webinterface for end-users in a way that they can only log service requests of the following types (afterwards they're screened by the Service Desk and classified according to the ITIL V2-cycle):
1. problem
2. question
3. demand
4. complaint

1 would be your typical incident, 2 & 4 remain service requests and 3 is your RfC. Users don't care what (ITIL-)classification you use afterwards, they found it hard enough already to choose from these 4. I've seen the "My computer is slow" logged as anyone of the 4 categories, so why do we bother in the first place? ;-)

We do although deliberetaly leave the real complaints out of our formal Incident mgt. because there's no direct solution, workaround,... and we feel it needs to be treated by another "proces" we aptly called "complaints mgt." We see this complaint category in terms of a subjective interpretation of events caused by a (lack) of service. Eg.: the technician insulted me, you had to come back 5 times to finally solve it, why do we still have to use that M$-shit,...

All complaints are formally discussed at the regular service desk teammeetings, escalated if needed, discussed,... and eventually closed in accordance with the user. Of course we can't satisfy everybody, but people are generally appreciative of the fact that their issues aren't being discarded but always treated in the same, formal way.

Luckily we don't receive many "real complaints" but in my experience there's always a lesson to be learned somewhere, so I feel it's a usefull little proces to have.

as a summary...

pjotrg — Thu, 11 Jun 2009 06:15:28 +0000

Even though we apparantly all want to give it another name and contain it yes or no within an existing ITIL proces, we do all agree that also the more untangible, non-technical moments of negative customer perception do need to be dealth with in a proper way.

I think it's not very important whether or not you use an ITIL proces to do so as long a you deal with it in a proper way.

Having sorted that out (with your permission ;-) ) I've got another one: how do we deal with compliments, positive feedback ? ;-)

Anyone Event Management?

Mr. H — Thu, 11 Jun 2009 01:06:10 +0000

According to ITIL Service Operation :

"An event can be defined as any detectable or discernible occurrence that has significance for the management of the IT Infrastructure or the delivery of IT service and evaluation of the impact a deviation might cause to the services"

A network working slower than usual (but inside SLA levels), bad manners of IT support personnel, an "ugly" user interface, a perfectly working but maybe "uncomfortable" process... those are occurrences that have significance for the management of IT services.

Why?

- Bad manners should be corrected to improve customer satisfaction and ease IT/Business cooperation
- An ugly user interface could be improved and users morale and productivity could improve
- An uncomfortable process could be the cause of change resistance and not compliance, and it can be improved

Event management is not limited to technical occurrences. All the before mentioned occurrences can impact services, and should be recorded and followed.

Indeed, but the point I

pjotrg — Wed, 10 Jun 2009 11:39:23 +0000

Indeed, but the point I wanted to make is that a complaint may follow a totally different route from "normal" incidents (which are more "technical"). Still it is important to track and trace complaints to. Complaints can be seen as indications from the user oragnisation that we have chances to improve our services!

The compliant example I gave was not very measurable. It was adressed at the servicedesk, but quickly dispatched to the manager of the technician in shorts. It was treated as a quality issue and was followed up a such.

Delivering services is not an easy job nor is measuring service. The tangible things can be easily measured, measuring perception is much more difficult.
Still a good technical quality delivered by unfriendly and unwilling people will be percieved as bad whereas a lousy service but deliverd with a big smile can be percieved as very good. Aren't we human?

Agreed

JamesFinister — Tue, 09 Jun 2009 20:05:05 +0000

I've put things like attitude, behaviour in the client's offices and dress code into contracts and SLAs before now

Rudeness might be a deviation from servicelevel

buraddo — Tue, 09 Jun 2009 19:56:16 +0000

Isn't a bit limiting to think of service quality in just terms of technical service levels. The way service is delivered is also contributes to the satisfaction with IT..

If a service delivery staffer abused me, but still met the service levels. Thats a incident in my book.. In fact, an incident that might be logged at the HR help desk.

Brad Vaughan

According to it MOF 4 stays closer to ITIL than V3

aroos — Tue, 09 Jun 2009 16:33:14 +0000

Yes, I have seen it. It is interesting that the document puts MOF in between of ITIL V2 and V3 Incident Management.

"...MOF on the other hand stays much closer to the ITIL V2 practice.."

How many times I have heard that V3 contains the V2 processes.

You've read the satirical

skeptic — Tue, 09 Jun 2009 04:35:39 +0000

You've read the satirical Introduction to Real ITSM :

• Complaint: complaints are a form of feedback but they are best dealt with separately, so that they can be ignored in a more focused manner and so they can be reported separately (or not at all).

Possible Solution

Visitor — Mon, 08 Jun 2009 16:03:34 +0000

Re-route complaints. If you listen to a complaint you'll possibly have to consider whether or not it's an incident or blah blah. Re-route the call to the guy who sold the product/service etc. They or (general consumer ignorance) are generally the cause of all consumer complaints because they mis-represent the product/service in the first place.

You don't need ITIL for that either ;-)

Is mise le meas,
Visitor

That's what MOF v4 does

jvbon — Mon, 08 Jun 2009 15:11:26 +0000

Aale,
processes can be designed as activity clusters in many ways. MOF v4 does exactly what you describe. It's kind of playing leap-frog with ITIL. Have you read the ITIL v3-MOF v4 Cross Reference that was just published as a MOF Companion Guide by Microsoft? It's here:
http://go.microsoft.com/fwlink/?LinkId=151991

Brigitte

skeptic — Mon, 08 Jun 2009 10:35:51 +0000

I worked one place where we argued over who got to call the service desk, just ot hear "'Allo. Thees ees Brigitte. Can I 'elp you?" in the sexiest French accent. In those days women in IT were very few and far between :)

The servicedesk is the cargbage can

pjotrg — Mon, 08 Jun 2009 09:45:20 +0000

Nice and classic discussion. Indeed Jan, we should not be to dogmatic ;-)

To make a distinction between incident and a complaint I always use this example:
The office manager of a high standing bank office (e,g, on the Champs Elysees, Paris) calls the servicedesk to tell that all worskstations in his bank office (on a very very busy day ! ) are out of service. This is clearly an incident. Technician (who is located at the other side of Paris) jumps on his motorbike, get there in 10 minutes, fixes the incident in another 10 minutes. Incident closed.
An hour later the same office manager calls again. He says he's very happy about the speed and quality of the resolution, but that he is absolutely NOT satisfied about the way things are solved. He complains about the technician being dressed in shorts and an open shirt and behaving very rude and unpolite against bank staff and their customers. Now that's a complaint in myn opinion.

We at Dutch Telecom, way back in 1998 in the ITIL V1 era ;-), had the same sort of discussion while setting up a Servicedesk for our outsourcing service. We assumed that a user would not call the servicedesk just for fun ( OK, I know even that kind of users exists, even those who call just to hear the voice of the female operator.... ), so we decided that we wanted to be able to dispach, track, trace and follow all calls. We "invented" a call process which handled this and shifted all calls in:
- incidents
- request for change
- service requests (in our definition: small jobs to be done by IT, neither being incident nor change. Things like fill toner, abort print queues, print jobs, etc.)
- requests for information, like status of an incident, "where do I find", "how do I print in bold"
- complaints
- other/undefined (all other calls)

We adapted our servicedesk system (ARS/Remedy at that moment) so that every call could be given a reference number (to give to the user who called). The trouble we got afterwards was of a technical nature: a call gets classified as an incident. How to transfer the date into the incident database, without changing the reference numer and without creating redundant data or corrupt numbering but still being able to trace back the reference number easily. That gave us a lot of trouble. so basically the idea was nice, the (technical) implementation at that moment was hardly impossible.

Hi, Whether or not a

Mark O'Loughlin — Mon, 08 Jun 2009 09:22:29 +0000

Hi,

Whether or not a complaint is an incident or a service request, complaint handling should have its own distinct 'process' (or could it be a 'function'?). Complaint handling should be concerned with finding the "conditions of satisfaction" and trying to satisfy this (in as much as possible). A service management system could be used to record the complaint but I suggest that it needs to be configured with appropriate fields and workflow to achieve the objective rather than just logging an Incident or Service Request.

or it could be a Problem..

Harvey — Mon, 08 Jun 2009 08:01:07 +0000

The service could be within SLA but the caller's service is still marginal.. e.g within the 99/100 limits but the 1 affected user happens to be the same one each time. This is particularly true for statistical measures e.g VOIP quality where it falls within limits but is still unacceptable to the user and hence the complaint.

Service does it using the IM tool

aroos — Mon, 08 Jun 2009 06:46:55 +0000

Jan
This is the same argument we had a while ago. You had such a good point about keeping the process simple so I gave up.

After that discussion I have asked a couple of SD managers how they actually handle complaints and it seems that most have just added complaints as an additional class, along with incidents and service requests. It seems that most of the IM applications have more classes than what the book says.

When ITIL V4 or whatever that succeeds V3 comes, I think it should have one Customer Service process with several sub-processes for handling incidents, faults, service requests, sales, complaints and other feedback. It all comes to the same SPOC anyway and they usually have just one tool for recording calls.

Aale

think out-of-the-ITIL-box

jvbon — Mon, 08 Jun 2009 06:15:10 +0000

With all due respect, I think this is an example of 'classic thinking'. For the challenge of understanding the nature of a "complaint" you should think out-of-the-ITIL-box. There are only a few customer-facing processes in ITSM. Find these and you'll understand all of the interfaces between customer and provider in an IT setting. ITIL largely missed the boat here from version 1 forward. Another way of putting it: ITIL never meant to provide that kind of structured information in the first place.
NB: this is a very personal opinion. It definitely is not what the fleet of ITIL-following consultants will tell you. But then again: who says the church (in whatever flavour you can find it) is right?

I say: think out-of-the-ITIL-box. There is a truck-load of service management knowledge outside of the IT domain available to help you out. Once you understand that, you can put ITIL to good use.

Confused

buraddo — Mon, 08 Jun 2009 04:54:03 +0000

So if a system throws an error that was previously unknown and a ticket is created, what is that ? My assumption is incident.

If the error is found not to have created a service deviation, does it become something else. The incident definition used to talk about "or may cause a deviation in service", which means you don't have to pre-analyse the fault to determine impact to that level. A complaint would mostly fall into the category "or may cause".

I always thought a service request was a documented process that was driven from the service catalog, not a catchall. I think the service request definition is now "information, advice, routine change and/or initiation of service". You might be hard pushed to stick complaint into one of these categories.

Please quote the book on me for this one, because my detailed knowledge is fading in age.

$0.02

Brad Vaughan