Customer satisfaction is good for business

The quote “if you build it, they will come” (of rather “he will come”) is from the movie Field of Dreams (1989) and often used to indicate that if you take a chance, good things will follow (or something of the kind).

I was reminded of this in the most wonderful and service management related way the other day, when I was part of a management-team meeting of our company. Our organisation (a service ‘outsourcer’ by lack of a better word) is set-up according to our various customers, who are each managed by a ‘Service Delivery Manager’ or SDM; kind of a Service Level (Process) Manager in ITIL terms.

One of the great things about our company is that these SDMs are not primarily managed on financial performance figures, but on service targets. There is financial oversight, but this is more looking at trends rather than at the performance of a single month.

We understand the theory of this: service deliver value or rather value-for-money and as long as the customer is satisfied with the value received, they will pay the money\cost\price involved.

This is actually not as common as you would like to hope\see in the industry where plenty of organisation are chasing the mighty dollar (or currency of your choice).

During the management meeting the financial trends were presented, together with some other corporate governance KPIs, mainly the customer satisfaction ones. We have ‘independent’ relationship managers, who perform standard customer satisfaction surveys at each of our customers, twice-a-year. The key KPIs are the satisfaction of the customer with the service from, and of the relationship with our organisation.

In general we cannot complain about customer satisfaction. We have ‘100% referencability’ in our core values and so far (18 years+) we have not lost a customer. This despite the fact that we discuss (and even plan) ‘transitioning out’ as part of our service design. It’ll be interesting to see if this works (if\when it is ever used) and whether we’ll be able to maintain referencability even after we've parted with a customer (we think this is possible).

Compare this to a recent transition meeting between us (as the new provider) and the incumbent (and leaving) provider; we witnessed a literally high-fiving project- and account-manager of the other organisation as they had increased their fee\price for the transition OUT. Not really a long-term view.

But back to the customer satisfaction KPIs. They showed a range of satisfaction, ranging across the usual scales of 1 – 5 (with 5 being extremely satisfied). Only a few of the customer were around the median of neither satisfied nor dissatisfied (and the rest above). Interestingly we mostly saw a slightly higher score on the relationship satisfaction than on the service target one, which indicates that the customer more-or-less understood why targets were not always met.

With two customers in particular it was ‘hard going’ during the past year. In general theses were relatively new customers and we had to work hard on maturing our relationship with them and the service agreement in tow.

This is actually a common occurrence: after the honeymoon of a new contract and the transition period, there is normally a phase of some tension. The agreement\contract may have been overly strict or 'aspirational' and/or not everything has turned out the way it should have. Black-and-white the customer will blame the outsourcer for this (lack of delivery), and the outsourcer blames the customer (lack of information\participation). In extreme cases this is where an SLA becomes the stick to hit each other with, depending on whether something is or isn't defined within.

However, if both parties manage to work together through this period, this normally leads to a contract variation which is more realistic for both parties. This then becomes the start on which a more constructive relationship can develop leading to better outcomes.

This is not just theory, but something that actually happened with those two customers in question and we saw the service & relationship satisfaction increase when the contractual hurdles were addressed and the focus was turned towards beneficial outcomes (for both).

Next was the presentation of the financial performance of each of the contracts. Luckily for us did most accounts show a healthy performance. It became interesting again with those two specific customers where the first part of the year showed a declining (‘though not necessarily negative) performance.

This trend was turned at roughly the same time when satisfaction turned around as well!

And remember that our SDMs are not managed on financial performance, this was the first time they actually were shown these numbers. During the year they had been focusing and working on meeting the service targets and changing the relation with the customer. This hard work, focused on service performance, not only showed success in that area, but subsequently changed the financial performance of the accounts as well!

What a powerful message: rather than focusing on financial performance it actually pays for an outsourcer to focus on service performance and the relationship with the customer. To paraphrase the quote from the start: “If you give them service, the money will come!”

the ITIL Zealot
March 2013

Process for Process' sake

One of the most heard (negative) comment about ITIL is that it introduces bureaucracy. If have dealt with this topic before, but recently I was reminded again of how people sometime implement (and follow) process for process’ sake, without an understanding of the reason for the process, and thus the outcomes required.

Let’s start at the beginning, or rather with the theory. ITIL defines a process as

A Process is a set of coordinated activities combining and implementing resources and capabilities in order to produce an outcome, which, directly or indirectly, creates value for a customer or stakeholder

As many other people\trainers do, and as you can see from the highlighting\bolding above, the easiest way to explain a process is that it coordinates the activities you’re supposed to do (which makes it easier than ‘making it up as you go along’, more repeatable and manageable than ‘just doing what you think you should be doing’ and all those other behaviours we don’t want to see in Service Management.

To me this is the key of a Best Practice (something which is accepted and used), or rather the opposite of best effort. Best effort means that each individual is doing his or her best, but often without any structure, documentation, management. Introducing a process of coordinated activities means everyone will do those activities and everyone will do them the same way, thus creating a repeatable, manageable process.

Therefore the first characteristic of a process is that it is measurable. After all if you can’t measure it, you can’t manage it and the coordinated, uniform nature of a process allows it to be measured (of course this is also where\when we introduce bureaucracy but that has already been dealt with in another blog).

A second characteristic of a process is that it has a trigger. In other words, we don’t just do something, whenever we want, but based on a particular trigger we start a particular process. I have a visual image of ITIL whereby all 27 process manuals (or 26 or ...) are standing on a boardroom table ... which process to follow? Fortunately above each process is an arrow indicating the trigger for that process: a call to the service desk triggers incident management, a submitted RFC triggers change management, the 2^nd Monday of the month triggers service level management (reporting). 

Maybe this is why the Strategy & Design processes in ITIL are so much more difficult to define. Cause where the Transition & Operations processes are quite linear (one trigger, one set or flow of activities, leading to one outcome), the Strategy & Design ones have multiple triggers, flows and outcomes. Again, I digress.

The last two characteristics of a process are that it has a defined outcome (the reason for the process in the first place) and a customer. Or stakeholder, there is some confusion here as it is not always the ‘business’ customer we mean here, but someone who wants the outcome of the process (after all why would you perform the process if no-one wanted the outcome).

And this is the ‘trap’ of ITIL. Because ITL defines the process, trigger & activities perhaps we sometimes to blindly just ‘implement’ what the book tells us, without considering the outcome or customer. This is the WHY of ITIL which is no readily apparent but certainly within the context (see by blog on that). Or perhaps after we have created a process (taking the outcome and customer into account), we proceed to merely follow the process, reviewing the KPIs but never verifying the original outcome, objective, customer and\or CSF\KGI.

It has now become process for process sake. My stock analogy for this is: ‘the operation was a success, but the patient died ... but look at those stiches, textbook!’. 

The other day I got a reminder phone-call from my dentist. This is a nice service they deliver as mostly I make my appointments 6 months in advance and this why I get reminded and it gives us the chance to reschedule if it is no longer convenient (from their side it avoids patients not showing up and thus increases utilisation and thus business revenue).

However, in this particular instance my previous appointment had been cancelled, and we had only rescheduled it to one day later. Thus receiving the phone-call reminding me of an appointment booked less than 24 hours before now didn’t add any value (or outcome), but instead felt like ‘process for process’ sake’.

the ITIL Zealot
July  2012