One of the biggest problems we have to deal with in IT service management (ITSM) strikes whenever we fail to meet the expectations of our customers and users. No matter how good the service, and no matter how well we support it, when we don’t deliver what people expect they’re unhappy.
I’ve worked with lots of IT organizations who regularly failed to meet expectations, and who don’t accept any responsibility for this. There always seems to be an excuse, for example:
Perhaps you’ve heard things like this in your organization; maybe you’ve even said some of them yourself. If that’s the case, then maybe it’s time for some serious reconsideration. If you want to deliver a great service to your customers and users, explaining why you can’t do things isn’t good enough. What the most effective ITSM organizations do is to take responsibility for managing customer expectations. Of course, this is easy to say, but not so easy to do. Here are my suggestions.
If you want to improve your organization’s ability to meet expectations reliably, then you need to do four things:
All four of these are important, and you’re most likely to meet your customer’s expectations only if you pay close attention to all of them.
In the rest of this blog, I’ll be examining these four things in a bit more detail. But before I start, there’s an important distinction to bear in mind (see Users, Customers – What’s in a Name?). ITIL distinguishes customers (who negotiate, agree and pay for the service) from users (who actually use the service). If you’re not familiar with this distinction, then think about a toy shop. The parents buy the toys but the children use them. When I talk about customer expectations I mean the expectations of both of these groups. Failing to consider the needs and expectations of users is just as bad as not meeting the expectations of paying customers.
If you want to understand your customers and users’ expectations, you need to talk to them. And you need to do it on a regular basis, because needs change over time, and expectations change in line with them.
Many IT organizations rely on SLAs to tell them what customers and users need. Unfortunately, SLAs may have been negotiated months or even years earlier, and are, in any case, often written by the IT organization rather than by customers. You may know and understand the SLA, but what about your customers?
If you use SLAs to plan and deliver services, then you need to discuss them with your customers AND USERS on a regular basis. Do they understand the targets? Are the targets expressed in clear business terms, or are they technical IT targets of little relevance to anyone else? Are the targets still right for their needs? If you’re not yet in the habit of talking to your customers, please don’t wait for the next annual review to come round. Unless you happen to be in the middle of managing a major incident, the best time to talk to your customers about their expectations is right now.
Sometimes customers do indeed have unrealistic expectations, and we can’t deliver what they expect because it would just be too expensive. For example, they may believe that you can deliver a service that responds in less than a second to thousands of transactions a minute, with all incidents being resolved within 2 minutes. Now how amazing does that sound?!
If you know what they expect and you really can’t deliver it, talk to them about it now. Don’t wait until after you’ve failed to deliver. Be honest, explain why this can’t be done; show them the potential cost of meeting the unrealistic expectation compared with the benefits. Sometimes this will be all you need to do to help your customers understand why they need to modify their expectations. On the other hand, you might be surprised to discover that the customer really DOES need that level of service, and is prepared to accept that they’ll have to pay for it. One customer that I worked with told the IT department that they wanted a service that failed over instantly. The IT department assumed that the 20 seconds needed for recovery after a RAID disk or cluster member failed would be good enough, but when I checked with the customer they really were prepared to pay what it took to fail over within ¼ of a second – because after that length of time the costs to the business would be enormous.
In any case, you need to agree what can really be achieved. When you have agreed, write this down, preferably using the customer’s own words. Don’t hide behind obscure technical targets. For example, many IT organizations specify a goal for percentage service availability. This could be 99.5% or 99.9%, but however meaningful this is to the technical staff, customers probably have no idea what it means. It’s much better to specify how often the service is likely to fail and how long it will take to fix. For example, “Complete service failure will happen at most 4 times a year and will be resolved within 4 hours” is much more helpful than “99.82%”.
It’s not enough to agree on targets with your customers, if you can’t achieve them. You need to make sure that you put in place whatever measures are needed to do what you said you would do. Let’s take the example we’ve just used. If you’ve agreed that “Complete service failure will happen at most 4 times a year and will be resolved within 4 hours,” then you need to think about how you can manage both of these numbers. What might cause a complete service failure, and how likely is it to happen? How can you make it less likely? How would you recover from this failure? How long would it take? What can you do now to cut the recovery time? This is all fairly standard risk management activity, but if you don’t have a risk register and you don’t manage your risks, then you’re just waiting to fail.
Finally, you need to talk to your customers about what you have actually achieved. Again, you should do this in terms they find useful. Don’t provide customers with a 200-page report every month if they just want to know what exceptions happened, but don’t just tell them what went wrong. The most important thing to do in a regular report is to tell customers what you are doing to improve. Explain what you are doing to make their experience better next week, next month, or next year. Discuss these improvements with them. Are you focusing on the right things? Will the proposed improvements actually make their experience better? Do they have suggestions to make?
What do your customers think of the services you deliver? Do you have good feedback mechanisms in place so that you really understand how they feel? Mechanical customer surveys have a part to play, but nothing can replace getting out there and talking to your customers, AND your users. If you make sure that you understand what they want, that they understand what you can deliver, and that you are working together to ensure the best value from the IT services that you manage on their behalf, then you won’t have any problem with managing customer expectations.
You can read more about customer experience in my white paper ”Back to ITSM Basics” Might Not Be What You Expect.