ITIL Service Design

Service Design connects the Strategy with Transition and Operation, providing tools to create and redesign services aligned with strategic objectives. It takes care that service management is fully aligned with business needs and uses its capabilities in an efficient and resilient manner.

Purpose
To design IT Services in a cost-effective, secure manner and in accordance to Service Strategy, and to take care of designed service delivery having in mind customer satisfaction.
A set of design governance documents is defined: methods, best practices, procedures and policies.

Objective
Effective IT Service design using continual improvement methods, ensuring service alignment with existing and new business requirements.

Five Aspects of Service Design
deal with designing:
 • service solutions for new or changed services
 • management information systems and tools
 • technology architectures and management architectures
 • processes
 • measurement methods and metrics

Four Ps:
(we remember them as People, Processes, Technology from last version)
 • People
 • Processes
 • Products (services, technologies, tools)
 • Partners (manufacturers, supplier,  vendors)

Service Design Package (SDP)
Definition: "Service Design Documents defining all aspects of an IT Service and its Requirements through each stage of its Lifecycle. A Service Design Package is produced for each new IT Service, major Change, or IT Service Retirement"

ITIL V2011 Service Design Mind Map

Service Design processes:

Service Catalogue Management
Deals with management of information about all live services. Info has to be accurate and current.

Availability Management
One of the oldest ITIL processes, connected to SLM. Ensures that delivered services availability is in accordance with the agreed levels. Of course, in a timely and cost-effective manner.

Capacity Management
Another V2 veteran: Capacity Management wants to ensure that IT capacity (infrastructure and services) meets the agreed requirements in a cost effective (and timely, of course) manner. Capacity management spans through all ITIL lifecycles, since cost-effectiveness and efficiency are among the basic reasons for ITIL existence.

IT Service Continuity Management
IT Service Continuity Management (ITSCM) process is responsible for the alignment of IT services to Business Continuity Management.

Service Level Management
This is a matured key process, SLM ensures that all services are delivered as agreed. It is tightly coupled with other processes emerged from Service Delivery group. Main purpose of SLM is to improve communication and understanding of Business and Service Provider.

Design Coordination
New in ITIL 2011, this process became the central point of communication and control for all processes in Service Design stage.
Design Coordination process is in charge of all design activities, whether they are done through projects or Change Management. It ensures consistent design of services which are aligned with Service Strategy and will be properly prepared for Transition.

Information Security Management
ISM is a governance process which ensures that information security policy  is aligned with business security. ISM maintains and enforces the security policy.

Supplier Management
A fresh process which was probably introduced for better compliance with ISO/IEC 20000, same as Business Relationship Management in Service Strategy. Supplier Management ensures getting value for money from suppliers. All activities are included: negotiation, agreements, supplier performance management, seamless integration of underpinning contracts and delivered services.

ITIL Service Strategy

Service Strategy has the central position in the circular ITIL lifecycle model.
By a broader definition, strategy is a plan devised to achieve a long-term aim. Service strategy is therefore a systematic long-term plan designed by the IT service organization to achieve defined objectives.

A good service strategy should define a way to create and deliver a better value to the customer.
Main objective of service strategy is to recognize competitors and have them in mind when considering services which will in some way be better than the competition's.

Service management is regarded as a strategic asset in the service strategy stage.

Service Strategy deals with

• developing service markets
• service provider types
• development of a service portfolio
• financial aspects of service management
• business relationships and others.

Strategy provides the tools and guidance to an organization to step back from daily operation and view existing services in terms of

• costs
• risks involved
• their performance

Strategy is about the pure cause of services, not about effects and how-to’s.

Service Strategy deals with some key principles:

• Utility and warranty
• Utility is "what is the service"/fit dor purpose.
• Warranty is "how it works"/fit for use.
• Value Creation - what does the service do for the customer and how he/she sees it.
• Assets -anything that can help us to deliver the service. Assets are either resources or capabilities.
• Resource - a kind of physical assets: infrastructure elements, people, financial capital, applications.
• Capabilities - intangible assets: usualy the ability to create value.
• Patterns of Business Activity (PBA) every cutomer has activities which generate demand for services.
• Governance - defines how we implement and follow strategy, policies and processes.

ITIL V2011 Service Strategy Mind Map

Service Strategy Processes:

Service Portfolio Management
A service organization manages investments in services across the lifecycle by exercising Service Portfolio Management.
Service Portfolio Management enables customers to understand what services are available, why they should use them (and why from this provider) and what will be the costs. Also to govern the services in such a way to support Service Strategy.
It enables a service organization to determine weaknesses and strengths of their portfolio, what the priorities and weaknesses of their investment are and how to allocate resources according to these priorities and risks.
Service Portfolio Management deals with

• services which will be delivered (pipeline)
• services which are being delivered (catalogue)
• withdrawn services (retired)

Financial management for IT services

Financial management enables the service organization to measure the value of IT services and underpinning assets. It manages cost-effectiveness of IT Service Management.

Service organizations use Financial management  to achieve Better decision making, Change Speed, Better Service Portfolio Management, Financial and Operational control, Sense of service value.

In ITIL 2011 returned to key activities from earlier versions:

• Accounting
• Budgeting
• Charging

Demand modeling is focused on TCO of service provision to the customer.

Return of Investment (ROI) is the main value of an investment.

Business Relationship Management
This is a newly defined process in Service Strategy. Here is the culprit for the fact that Measurement and Reporting are not in CSI any more. Anyway, this is a welcome change. BRM existed for some time in ISO/IEC20000 and is widely recognized as a crucial process in IT Service Management. Its main purpose is to support most of other processes in all lifecycle stages - by helping Service organization and Business to better understand each other. Which is, as we know, the basic means/goal to all ITSM organized voyages. If Business and IT don't make an effort to speak the same language, to understand each other's pains, then all the other endeavors are meaningless.

Demand Management
Another new  process! Previously, Demand Management was dealt with inside of Capacity Management. On primary ITSM levels, it is the right place for Demand Management. But since we started dealing with Strategy and Design lifecycle stages, we saw Demand as the crucial driver for them. So here it is.

Service Strategy is the most boring ITIL book. It was most thoroughly rewritten in 2011., and it still helps me to fall asleep when all other methods fail :)
On the other hand, it contains some very important concepts and aspects of Service Management which tend to be more and more interesting as you gather experience working in IT industry.

ITIL 2011 Processes

Here is a clear and organized table of ITIL 2011 processes for you. What is where, what is important, what is old and new:

ITIL 2011 Processes Table

There are some changes from 2007 edition.

What is not so obvious from this table, most of the changes happened in Service Strategy. Strategy Generation is not treated as a process any more, rest of the processes are more uniformly described. New processes are Strategy management for IT Services and Business Relationship Management.

Some interesting changes in Service Design also: processes are better described and aligned, I like to see clarified Pipeline to Catalogue transition. New process is Design Coordination.

Less radical changes in Service Transition. Understandable, since these were mature processes. Except for Evaluation, which is now called Change Evaluation process.

Least changes in Service Operation. Of course, new Service Fulfillment and Event Management additionally clarified. Interesting , but not unexpected, Problem Management was polished some more. Looks like Problem Management was problematic from the beginning :)

Continual Service Improvement: of course, more changes. CSI model is now CSI approach. 7-step process has seven steps :)  What bothers  me a little is that Service Measurement and Reporting are not processes any more. Where I work, these are most important processes and the right place for them is in CSI.

Functions

All four functions are still Defined in Service Operation:

• Service Desk
• Technical Management
• IT Operations Management
• Application Management

Generally, I like the way things are developing. This is probably not the last of changes we will see in ITIL. TSO and Cabinet Office people are taking care of their baby.

ITIL 2011 - What Happened?

ITIL Lifecycle Suite 2011 Edition

As you can see in an excellent ITIL History article on this blog, ITIL has come a long way from first publications in late 80's. In July 2011 ITIL V3 was updated to 2011 edition.
Now folks, let's get down to basics. I will slowly go through changes and events and talk a little bit about every ITIL Lifecycle stage and what happened where. I am talking about my following posts here, of course. Those who know me understand the emphasis on SLOWLY here :)

So, we received a package of books which are 57% heavier (2,5kg increase) and have 46% more pages (+600) comparing to "old" 2007 V3 edition. Apparently, this increase was mostly due to thorough Service Strategy book rewrite, and of course a larger font used.

Service Strategy was the most vague and least accepted in larger ITSM community, so it really needed some serious rewriting. Other books were also improved to some point, a few new processes introduced, obvious ambiguities and errors removed (some new created), so the whole package looks more polished and admissible by the critical members of the community.

Complete list of Frequently Asked Questions can be found on APMG's ITIL Official Site on this page http://www.itil-officialsite.com/Publications/ITILPublicationUpdates.aspx  .

Also, a very fine summary of 2011 updates can be found on the same page. Look for ITIL 2011 Summary of Updates .

People at ILX Group were so kind to update their popular ITIL Process Model available free for download here: http://www.ilxgroup.com/downloads/itil-2011-process-model.pdf

Con
Critics among us will keep the mantra that the whole thing is a bit out of date and clinging to it's 80's roots, not referring enough to modern concepts of Clouds, Agile and Virtualization.
Also, they say that the vastness of material is repelling, supporting the complex Qualification scheme http://www.itil-officialsite.com/Qualifications/ITILQualificationScheme.aspx in a self-serving purpose to make more money.

Pro
On the other side, attaching tighter to modern technologies brings the danger of quicker obsolescence. Polishing general concepts made ITIL go this far, so "descriptive not prescriptive" motto lives on.
2000 pages is a lot, but it is fair to give the authors credit of the intention to cover adequately all topics in an integral baseline set of books.
For executives, beginners and innocent passers-by, Compact/Digest editions will probably follow soon, like this fine pocket book: http://itservicemngmt.blogspot.com/2012/02/new-itil-foundation-handbook-released.html

Anyway, most reviewers are happy with the overall 2011 update. Are you?

As I said, I intend to go through all five lifecycles in the following articles. Stay tuned.

What is Password Reset: Service Request, Incident or Change?

I browsed through a few social networks lately discussing basic Service Support activities like password reset. Interesting to see how even experienced IT professionals have different points of view on elementary procedures like this one.

One of discussions goes on and on about what is a Password Reset procedure: is it a Service Request, Incident or Change?
We can take for granted that these portals consider the simplest case of Password Reset event: the user forgot hers/his password. In a consolidated service desk of 2000s this was the most frequent event, making 50-80% of all calls.

Is it an Incident?
So, could it be an Incident? Obviously NOT. Incident definition requires a service downtime or probability of downtime. No service downtime here, only end user can't log in, by his own fault.

Why then a plenty of Service organizations treat these events as Incidents? Because of the Service Desk TOOL they (miss)use. They have a nice little tool which is ITIL approved by some elephant. It can do all the process, you name it. But implementation of additional modules costs money and time. They already have Incident Management. Their implementer sucks, their ITSM consultant could do better, and they are often the same person. So they created a category "Password reset" in Incident Management module and they treat password reset as an incident. That's why it has to be an incident. If the only tool you have is a hammer, every problem is a nail. Let's move further.

Is it a Service Request?
Is password reset request a Service Request? Of course it is, there it is in the ITIL definition of a Service Request:

• A request from a User for information or advice, or for a Standard Change or for Access to an IT Service. For example to reset a password, or to provide standard IT Services for a new User. Service requests are usually handled by a Service Desk, and do not require an RFC to be submitted.

So it's a small preapproved standard Change which is processed thru Request Fulfillment process.

Yes, it is a Change, but no need for Change Manager and CAB to get involved since it happens frequently and can be dealt with on the 1st level. And thank you God for technology you provided so that lately any end user password can be reset via a simple self-help portal. User just answers a secret question, puts in his employee ID and receives the new password via text message or such.

What other special flavors of password reset are there?

• Simple web application user passwords are a mild example of the above described case.
• Enterprise domain user password is closer to what first comes to our mind when we think about password reset. Now, we said it is a Service Request. In which cases it escalates to a Change Request? Well, if you have a strong security policy, implemented SOX or ISO/IEC 27001 and influential security officer, then it's possible that they require formalized approval cycle and implemented operational Standard Change procedure.
• VPN account passwords which enable user to connect from the outside of the company to internal network are a very sensitive security case, so all concerns regarding domain user accounts apply to them, and then some. A special case is a VPN account given to a 3rd party employee. Usually such a request has to have defined start and end of usage and approval from a high position (chief security, IT manager or CEO).
• Application Administrator account passwords enable the user to create a significant amount of damage to a company according to the importance of the application to the business. Examples: Intranet applications, CRM, ERP. Which one contains the most sensitive data for your company? Probably the ERP application.
• System Administrator Account presents the highest possible level of trust to an employee. Only security officer , Operations or IT Manager should approve these account creations and their password reset requests.
• Service Accounts under which different IT services are executed. These have to be taken care by the security officers, their catalogue has to point to services they enable (1:M relation) and access to their passwords has to be restricted only to most confidential people. Usually these accounts have broad authorization and they are set to rarely or never expire, so they should be maintained with utmost care, especially in organizations with frequent employee fluctuation. Best practice is to deposit them in a safe box by a single person.
   

Note: there are significant changes lately in best practices and recommendations with large vendors and consulting companies about the password lockout policy.
Until recently, the recommendation was to lock the user account after three to five unsuccessful attempts. What changed? Implementation of security standards and best practices introduced higher password complexity and more frequent user password changes. Majority of users have some kind of mobile device for connecting to an enterprise mail system. These devices cache user credentials and often lock-out user's accounts after password change. Virtualization also contributed to simplification of lockout policy since various user credentials can be cached on different physical and virtual machines.
Brute force attacks are measured in hundreds if not thousands of attempts in a short period of time, so it is now advised to lift the lockout attempt number to 60-100, or to turn the policy off completely and survey security logs with adequate tools.  

Let me just finish here in a nicer tone. ITIL is not too prescriptive in telling you how exactly to do things.
In the above example, if you process Service Requests as a special category Incidents, you are still in the green. Customers get their service, all needed reports can be generated as agreed, KPIs are there, you are good!

We are in business of keeping the customer business going. In the spirit of current holidays, I wish you the very best of luck with it. Because you are going to need it :)

For further reading I recommend 4.2 Incident Management, 4.3 Request Fulfilment and 4.5 Access Management chapters in ITIL Service Operation book.

Also, have a look at articles:

• Incident Management
• Change Management

ISO/IEC 20000 - A Brief History

From DISC PD 005 over BSI 15000 to ISO/IEC 20000. Specifications, requirements, Code of practice.

History is a myth that men agree to believe.
Napoleon

ISO/IEC 20000 Timeline

I have been looking around for some brief document with ISO/IEC 20000 history, and I could not find anything useful.

Here are a few major points I have collected from various sources in ISO/IEC 20000 history.

1995: British Standard Institution (BSI) published the first version of DISC PD 0005:1995 - Code of Practice for IT Service Management. It described only four basic ITSM processes.

1998: BSI publishes a revised version of DISC PD 0005:1998 and it already described all five process areas and 13 processes as we know it today.

2000: Published BS 15000:2000 - Specification for IT Service Management which was used together with the code of practice DISC PD 0005.
Also in 2000, the third supplementary document entitled DISC PD 0015:2000 IT Service Management Self-Assessment Workbook was published.  It was a questionnaire that enabled anyone to make an assessment of its compliance degree with BS 15000.
Some serious revisions and rewriting followed, resulting in standard documents very similar to today's norm:

2002: BS 15000-1:2002 IT service management - Specification for Service Management;
PD 0015:2002 - Self-Assessment Workbook

2003: BS 15000-2:2003 IT service management - Code of Practice for Service Management
The same year a new PD 0005:2003 Guide to Management of IT Service Management was published with explanations of the purpose of BS 15000, and also the framework guidance on how to use the standard processes and implement them.
BSI 15000 was adopted by many service companies in UK, and countries worldwide accepted it.

2005: BS-15000 was placed on the “fast track” by the ISO. By the end of the year, with some moderate changes, it was published as ISO/IEC 20000 standard:

• ISO/IEC 20000-1:2005 Specification  is very formal, it defines processes and provides assessment/ audit criteria.
• ISO/IEC 20000-2:2005 Code of Practice that gives HOW-TOs and describes best practices for implementation of Part 1.

Standard was unchanged for four years. Adoption was a bit slower due to somewhat lower ISO maturity level of the standard. The norm requirements were very demanding, and supplemental documentation was scarce and sometimes ambiguous. There was a need for some additional documentation:

2009: ISO/IEC TR 20000-3:2009 Guidance on scope definition and applicability  was published. It provided guidance on scope , applicability and of conformance for service providers

2010:

• ISO/IEC TR 20000-4:2010 Process reference model - describes  the service management system processes implied by ISO/IEC 20000-1 at an abstract level.
• ISO/IEC TR 20000-5:2010 Exemplar implementation plan for ISO/IEC 20000 -1 - provided guidance  to implementation of ISO/IEC 20000 by example and advice.

2011. April:  ISO/IEC 20000-1:2011 - new version of specification is out.

2012. February: ISO/IEC 20000-2:2012 - new Guidance on the application of service management systems published.

If someone has an update or a correction to this, I will be very glad to update the post. Thank you.

Related posts:

ISO/IEC 20000 Essentials
A few more words on ISO/IEC 20000

ISO/IEC 20000 Rediscovered
Describing differencies and similarities of ITIL and ISO/IEC 20000

ITIL and ISO/IEC 20000 Compared
ITIL V2 - ITIL V3 - ISO20000 comparisson table

Hope this helps. Have a nice day!

ITIL Major Incident - All you want to know

What is a Major Incident in ITIL? What are the roles and responsibilities? How to avoid common mistakes? What to do After the Resolution?

Trust me, I know what I'm doing!
Sledge Hammer

What is a Major Incident?
Definition of a Major Incident has to be clear to every employee in Service Support. Therefore it has to be clearly described in a separate document, Major Incident Procedure.

What makes a Major Incident? It is usually defined by the impact outage has or could have on customer’s business process. Also, it may be determined by priority of the incident or by its urgency.

How come that the impact isn’t allways the only factor in defining the Major incident? For example, an incident of high impact can be resolved by Service Desk thru a simple resolution procedure, like switch resetting after network down event, or connecting a backup provider after internet down event.

Both examples are definitely high impact but we don’t have to recruit a bunch of higher level people on it just yet. We just have to have in mind that they are Priority 1 and they have to be resolved ASAP. In case they can’t be resolved by standard procedure, THEN they can be marked Major and handled with appropriate procedure and policy. That’s why most leading Incident Management tools on the market have a separate checkbox Major or Hot incident.

This was all theory. In practice, to simplify the procedure and make it easier to Service Desk staff, this is what I usually advise: all priority 1 incidents are Major Incidents, if they are not exceptions. Exceptions can be easily defined for particular customers, contracts and incident categories. For example: Major incidents are all Priority 1 incidents except cash register tickets, which are urgent but can be fixed by technicians, no need to involve for more important people. Or: all categories except end user incidents. Simple.

Major Incident Team

OK, now we have determined it’s a Major Incident. What next? We establish a Major Incident Team. Members are:

• Service Desk Manager – he will be responsible for communication with resolution team and timely reporting to the customer
• Incident Manager – in reasonable service organizations Incident Manager is usually also the Service Desk Manager. If not, then these two have to work closely together.
• Major Incident Manager: a frequent mistake is to promote Incident or Service Desk Manager into Major Incident Manager. This doesn’t have to, but can cause some serious conflicts of interests: he has to survive somewhere between Incident Management, Problem Management, Business Management and the customer.
  Major Incident Manager has to be a liaison between all internal parties involved, also acquainted well to technical aspects of the outage. So he will often be recruited between people formerly engaged in a project, or those involved in service catalogue definition.
• Problem Manager: remember him? He will be most helpful here in investigative phase, towards closure phase, and a life saver in post mortem reporting. Better keep him on our side. Mind you, Major Incident is still an incident, but usually has some underlying cause which will be recognized as a Problem. Hence Incident and Problem Manager have to work closely here, each with his own goal in mind (service restoration vs. underlying cause).
• Other members of Major Incident Team: representatives of all people involved, impacted users, competent technical staff, vendors... Good practice would be to choose people here the same way you would choose ECAB (Emergency Change Advisory Board) members. There is always a chance that you will be implementing an Emergency Change during a Major Incident resolution process.

Resolution Process

Major Incident resolution works on tight SLA parameters. Service Desk takes care of them. Also, ticket updates and frequent feedback to customers is performed by Service Desk. Remember, customer hates to be kept in the dark, even if news are bad (no progress) they must be updated frequently.

Major Incident Procedure has to define the escalation policy in case of SLA breech. Usually the incident is escalated vertically to higher level IT / Business management and to vendors of services/equipment underpinning the service.

After the battle

Upon the resolution, Incident Management Team stays “on call” and monitors the service for the period defined by Major Incident Manager. He also schedules a short team meeting for the next day.

Incident Review is performed on this meeting, points for improvement and lessons learned are defined and Post Mortem Major Incident Report is created.

Incident Manager sends the report to the customer.

I have prepared for you a template for Major Incident Report, free for download here.

Related posts:

Incident Management Elements
Key elements of Incident management.

Incident Management Mind Map
Download the incident management mind map.

All About Incident Classification

How to deal with incident categories.

What Everyone Should Know About Incident Priority

Incident prioritization in ITIL.

Hope this helps. Have a nice day!

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?

USA Today has come out with a new survey - apparently, three out of every four people make up 75% of the population.
David Letterman
 
In my last post I spoke about Customer Satisfaction. OK, but how to gather data? How to interview customers? How to get the best results in surveys and help educate the customer about the proces?
Here I give you a list of basic ITIL methods for gathering customer satisfaction data and my coments of its worth in my company. Mind you, we are in Managed Service business, so my grades are biased.

If you are a small IT in  government agency or an IT in Airline company, you may look for different values. Still, this will give you an idea.

Customer Satisfaction

After-Call Survey

Callers are asked to remain on the phone after the call and then asked to rate the service they were provided.

This method requires that you have some kind of telephony automation like Interactive Voice Response (IVR). The thing with this method is, however you set the system it will often be despised by the customer. Most of the people don’t like to hear recorded messages and even more people hate moving down the menu tree with phone keyboard. Outcome? Only extremes: customer which are very satisfied and wish to reward an agent by giving him good grades or, more often, a very pissed off customer who will go out of his way to express his low level of satisfaction.

Call Center organizations are doomed to use this technology since phonecalls are the only way of communicating with the customer. In ITSM there are usually more ways to talk to customer.

My worth: 1/5

Mail Surveys
We never considered sending mail interviews to customers as an option. Not in this century at least. What kind od IT-related person would fill the received paper form and send it back to us? Do we need a feedback from this kind of person? No, thanks.

With e-mail it's maybe slightly better. We used to have a ServiceDesk application which would send an automated notification on incident resolve event, asking the customer contact to reply in an email grading their satisfaction with speed and quality of resolution by grades 1 to 5. So lame. Response percentage of 0,05% was enough to pacify our ISO9001 auditor but it was next to worthless to us otherwise. One good thing was that receiving a small number of answers in an unstructured text email made the result processing much easier :-)

My worth: 1.5/5

Group Interviews

In this method, customers should be gathered in small groups and interviewed together. This can maybe be somewhat useful in a group of people working together, even then their answers will be biased and dependent. Possible value I see in this one is that they will help to develop communication between customers of different knowledge levels and enhance collective process knowledge.

In my organization we try to keep different SLA customers as far from each other as possible. We do not conduct group interviews but we do organize ITSM workshops here and there for our customers, feedback is usually very good.

My worth: 2/5

Phone Surveys
Some time after the interaction with Service Desk, an independent agent calls the customer.

You are in the middle of your monthly report, juggling a database and three spreadsheets, and some guy calls you to grade your experience with Service Desk from ten days ago? You will brush him off. OK, maybe not the first time, but the next, for sure.

So, if you want to get the results with this method, you need trained people with strong communication skills and good opening lines. Also, a good idea is not to have surveys for all calls, to let the customer rest from you periodically. If they anticipate your call, they start thinking up good excuses to brush you off. Surprise them periodically.

My worth: 2/5

Personal interviews

Surveying person is usually Incident Manager or Service Desk manager, while the Customer representative is a person responsible for SLA on their side. These can be contact persons on Major incidents after the post mortem reporting, but that’s another story and this should be defined in Major incident procedure.

These interviews are usually periodic and should be conducted at least annually (usually they are, during a contract renewal), but more preferably on quarterly basis. During these, the two parties communicate customer needs and help focusing Service Support towards things important to customer. So the questions in a survey should be aligned with Service Desk and Incident Management KPIs.

These are of great value to us.

My worth: 4/5

Online Surveys

We worked with several Service Desk automation tools, different vendors. In the end, we developed a Web application which enables us to send different surveys to our customers. They can be Ticket related, periodical or Ad Hoc surveys with predefine templates of multiple choice and freeform answers. We like it so much that we host it to other departments of our company. And we do not sell it, it’s that good :-)

Customers fill it in their own convenience (ok, we sometimes call and beg them to fill surveys), and after they submit the form they are automatically in the report.

Web-based surveys are a life-saver to us.
My worth: 5/5


Other Methods
Blogs, tweets, wikis, forum discussions and chats are all nice to have and, if maintained well, they will influence customer experience positively.

However, it is next to impossible to mine a structured measurement of customer satisfaction out of them, and they shouldn’t be used for that purpose.


Additional About Surveys

Scoring
It will be best to define simple questions with multiple choice number ratings. How many different grades? For fine gradation in longer interviews we use grades 1-10. For faster, ticket-focused surveys we opted for a coarser gradation. We used 1-5 for a long time, but a lot of the grades were distributed to 1, 5 and 3. Eliminating the middle value and shifting to 1-4 made our customers think more. We still use (1-4) system for most surveys and we are satisfied with it.

In addition, it is often nice to put an optional comment field under every question. Doesn’t cost much, and sometimes customers leave very useful info there.

How many questions?
You certainly don’t want to scare of the customer with a bunch of questions. OK, annual interviews can be longer, and internal ITIL/ISO20000 audits and assessments can gave a gazillion questions, but survey on incident performance can have only one (how satisfied are you?), ideally three, or maximum five multiple choice questions. You fish for quantity here.

Anonymous or named?
Some customers will answer an anonymous survey rather then named. Well, their problem. This is one case where customer is not always right. You want to know who is satisfied, who is not, so you can decide on your further actions.


Related posts:

Customer Satisfaction in ITIL Service Management: Do You Get It?
Elementary facts about ITSM 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?

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?