ITIL Service Management: 2010

Nov 30, 2010

Customer Satisfaction in ITIL Service Management: Do You Get It?

Customer Satisfaction: How bad do we need it in IT Service Management? Where is it mentioned and where is it dealt with in ITIL V3? How do we manage it in real life?

- I Can't Get No...
- I'd rather be dead than singing "Satisfaction" when I'm forty-five.
Mick Jagger

Customer Satisfaction is very important. One of the main ITIL highs is to put a customer in focus. It is usually done by finding ways to raise the level of customer satisfaction. Often by creating a common language for better communication between the Business and IT.

Implicit, customer satisfaction is mentioned in all ITIL processes and functions. Explicit, there are parts of ITIL where we really take care of it. Where is it?

SERVICE STRATEGY
In Strategy stage of ITIL Service Lifecycle we are talking generally about opportunities, markets, possible services, where we are, where do we want to be. Here is where we firstly define the level of satisfaction we want to achieve. New people in this field think that a customer satisfaction should be as high as possible. Sorry but that's not the case. If customer is super satisfied it often means that we are over delivering, and he gets more then he paid for.

PERCEPTION
Satisfaction is about PERCEPTION. So, it is not about real objective quality of service, it is about how customer sees that quality. There are cases when a customer sees the service much better than it is, and also, sometimes the service is perceived much worse than it is in reality, usually due to bad communication, or a few isolated cases that gained higher visibility.

Customer interacts with service and compares its quality. To what? Not necessarily to a previous or existing service provider service, but always to his own EXPECTATIONS. That's why

Customer satisfaction = Perception - Expectation

And our life depends on staying on positive side of this equation.

SERVICE DESIGN
Design is a phase where we define a new service. In the end of design phase we know where we want to be and how satisfied our customer should be. Main places where we define customer satisfaction are Service Level Management, Availability and Capacity Management.

Service Level Management
Now we are at the right place.

The goal of SLM is to ensure that the agreed level of IT service is provided. And that any services we will provide in the future will be delivered as agreed.

The alleged purpose of SLM is to provide the metrics for conformance of the achieved level of service to agreed one.

But in reality, the main goal of SLM is improvement of communication between Business and IT. The process of SLM is the most important and valuable process in creation of the service. It helps Business to KNOW what to EXPECT and also helps IT to know what is important to provide.

Service Level Agreement (SLA) is just a document. But the process of SLM helps IT and the Business to understand each other. Negotiations, request weighting, estimations, it all helps Business to understand what resources are involved and how difficult it is to achieve every little fraction of availability percentage. Also, SLM process helps IT to understand what and how is really important to business. So SLM is about bringing EXPECTATIONS in reality domain.

Service Availability and Capacity Management
Availability and Capacity are naturally opposed and they represent the process of narrowing the gap between what customer wants and what he is willing to pay for. IT is here to try to comprehend what is important to Business in order to stay alive in a cost-effective way.

So Availability and Capacity underpin the process of Service Level Management by educating the customer about the price of the service and finding the optimal investment/gain ratio. Customer will understand that price of availability grows exponentially. Simple math will find the adequate crossing of the cost and availability curves.

That's why ITIL says that "there is a direct correlation in most organizations between the service availability and customer and user satisfaction, where poor service performance is defined as being unavailable. "

Better communication and common language helps IT to stay alive even if some services deteriorate. It is still possible to retain most of customer's satisfaction if he knows he can have confidence in us.

SERVICE TRANSITION
Customer satisfaction is mentioned as a factor of high importance repeatedly in Service Transition Fundamentals and Principles.

During Transition, in Change Management and especially in Release and Deployment Management we get in touch with the customer and it is very important that these interactions create good experiences.

But, if we get to this ITIL implementation stage and something goes wrong, it will usually be much more visible in Operation phase, since badly implemented changes create a large percentage of RFCs and incidents.

SERVICE OPERATION
Most interaction with the customer happens in Operation stage, mainly in Service Desk function, through Request Fulfillment and Incident Management.

What we want to do is to optimize costs and quality in agreed service level:

Finding the Cost/Quality optimum for the Service

Customer satisfaction is the main KPIs for these ITIL entities. Most of the non-technical introduction to Service Desk chapter is actually about Customer Satisfaction. There is even a nice detail about customer/user satisfaction surveys (6.2.5.1).

CONTINUAL SERVICE IMPROVEMENT
A lot of attention is naturally given to customer satisfaction in Continual Service Improvement. Satisfaction is something you can measure, and what you can measure you can manage and improve.

Where I am from, gathering and reporting of customer satisfaction data is done in Service Desk, mostly after incident ticket closure and periodically on meetings with top ten customers. That conforms well to our ISO 9000 and ISO 20000 requirements. Every year on management review we check did we reach our last year’s goal, and define where we want to be next year. Let me remind you: it is not always about rising customer satisfaction: one year we even lowered target values of Incident Management survey results.

I have a few examples to illustrate the above for you:

Anecdote 1: In the early days of our service support we had a customer. We were over-capacitated and eager look our best, so we responded and resolved tickets for this customer much quicker than the Service Level Agreement required. Customer was happy. As we got more customers, our response times became longer and longer, but still well within SLA parameters. Our customer started to send unhappy signals in our regular satisfaction surveys, so we scheduled a meeting.

Problem wasn’t in our agreement, but in perceived deterioration of our service. Customer took our eagerness for granted. So we had a long talk, reset our SLA thresholds and financial parameters, and continued to cooperate. Nevertheless, we took care to respond to system incidents after 1/3 of agreed response time. For all customers. Just in case.

Anecdote 2: During the night, our system monitor tool notified our Service Desk on a major incident at our customer’s site. Our on-call engineers were called and started investigating immediately. They spent all night working on resolution and succeeded early in the morning.
Sadly, our Service Desk did not open an Incident in our ticketing application until the resolution. So customer was notified about the incident 5 hours after the service went down. And in SLA we have defined 2 hours response time, hourly notifications on priority 1 incidents, and resolution after 8 hours.
Our customer went wild (very dissatisfied). Even if we worked all night with doubled capacity to restore the service, we failed to meet the agreed notification time and kept the customer in the dark.

On the other side, if we only had created the incident record and notified the customer hourly that we work on it every hour, put one person on resolving it until the morning, our customer would be much happier.

Service Level Management is KING
Of course, there are all kinds of customers, some are nice people and some are less so, but at the end of the day, it all comes to delivering what you promised. So if your Operations processes are implemented well, usually a significant improvement can be gained by working on your Service Level Management process.

Opening Jagger quotes were just for my amusement. Here are a few Customer Satisfaction thoughts that I picked up for you:

- Your best customers leave quite an impression. Do the same, and they won't leave at all.
   SAP Ad

- Although your customers won’t love you if you give bad service, your competitors will.
   Kate Zabriskie

- Customers who don't get support become someone else's customers.
   Brigade Ad

- If the shopper feels like it was poor service, then it was poor service. We are in the customer perception business.
   Mark Perrault, Rally Stores

- You are serving a customer, not a life sentence. Learn how to enjoy your work.
   Laurie McIntosh

Related posts:

Customer Satisfaction Survey: What Methods To Use?
How to gather customer satisfaction data? What methods are there? What ITIL says? What methods will work for you?

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?