The Power of Service

In preparation for my itSMF-A LEADit presentation in Canberra this year (‘Around ITIL in 30 analogies’), I was having a good look at the various analogies I use during my training and other ITSM related activities. I love the use of analogies as it is an easy way to explain complex, abstract concepts such as service management.

This was confirmed when last week I was delivering an ITIL Foundations course, using many of those analogies (sorry, you’ll have to come to the presentation to hear them all) and once more seeing their effect. In particular when explaining the concepts of service management and a service I spent a lot of time emphasising that this is not so much about ITIL, but more ‘zen’, a state of mind whereby the whole organisation is focused on delivering value to the customer, in a fixed-price, black-box, guaranteed, repeatable and managed way.

ITIL is merely a way of achieving this (and then only the Process-part of the 4 Ps). In the course we then move into the various processes and their intricacies. It is not until I reach the Service Desk function (in our course, on the last day, after all the lifecycles & processes) that I truly get to focus on the delivery of service again.

This of course as the Service Desk is the Single Point of Contact for the User and as such the visible part of the IT Service organisation. I have once before sung the praises of the Service Desk and how important it is to get it right [HERE]. But I extend this by explaining how important service (perception) is, far more important than (product) quality.

Take for instance a mobile phone (an easy to understand analogy, as most of us will have one). If you buy a mobile phone from shop X and it never fails, you would be a satisfied customer. And when it comes time to replace the phone, you may go back to shop X, but perhaps shop Y has a better offer at the time. The perfectly delivered product (meeting service targets/expectations) has not generated a particular relation\commitment with the provider.

On the other hand, if you buy a phone and it breaks, you’ll take it back to the shop. If this shop is hard to reached (closed, not answering phones, …), not friendly (‘have you touched it’, ‘it’s your fault’, …) and not good in their response (they’ll charge you, take forever to repair, …): you will never go back to this shop. A bad service has destroyed the relation.

But if, when you go back with your broken phone, the shop-assistant is most apologetic and offers you a satisfactory solution (replacement, credit, …), not only are you walking away a satisfied customer, but you will almost certainly come back to this shop for future purchases (provided of course the phone doesn’t break every month). The excellent service here has turned a negative (broken phone), into a positive: a satisfied customer with an improved relation with the provider.

Now, this part of the service is often called ‘service’ as well, although it is far more intangible, more about perception. It is the people-aspect put on top of the actual service delivery against its targets. This is things like the availability of the Service Desk, the friendliness of its staff, the response and follow-up provided.

A bad product (or service) will lose you customers, but a good one will not necessarily gain you any. People more or less expect this and you won’t get credit for something that work the way it is expected to. This is a similar issue as Problem Management faces, in particular the pro-active part: the better you do, the less people notice it!

However where bad service-perception will also lose you customers, good service will gain you. Perhaps not so much new customers, but it will cement and improve the relation with your existing ones. Hopefully improve this beyond the black and white numbers of the contract, but more into a mutually beneficial relationship whereby the IT Service Provider is truly able to provide service (and added value) to the business.

So, back to the starting point of explaining concepts: Whilst ITIL has a definition for service, and explains the function of the Service Desk … people (in my case course attendees) need to understand the true objective of a service, one that goes beyond ITIL, any of its process or functions and should be at the heart of all your staff and their actions: delivering value to your users\customers!

the ITIL Zealot
April 2013

Around ITIL in 30 Analogies

This week I received acceptance of my presentation proposal for the itSMF Australia national conference LeadIT 2013 (in August, in Canberra). My topic of choice is ‘around ITIL in 30 analogies’.

Yes, I’m realising that these details will make it possible for you to discover my identity as I have submitted the above under my own name (and will not be on stage dressed in a black robe). However, after all this time it now is time for me to ‘dis-robe’.

Anyway, back to the topic. I love analogies, I think that analogies are just about the best thing since sliced bread (is that an analogy in itself?). When it comes to training there is no better way than to quickly explain a concept than to relate it to something already (and/or easily) understood by the participant.

This is not a matter of ‘dumbing’ things down or ‘populising’ a concept, but a valid way to provide a better understanding. And let’s face it: the ITIL theory is full of concepts and whilst they may claim to be ’common sense written down’, sometimes common sense isn’t common (and it doesn’t always make sense either).

My favourite analogy is that for a service. After all, this is the most basic concept of ITIL Service Management. The official definition of a service is “A means of delivering value to Customers by facilitating Outcomes Customers want to achieve without the ownership of specific Costs and Risks.”

True of course and there are many things to be learned from just slowly reading the definition and looking at the keywords. Apart from analogies, another technique I use to explain concepts is to bring them down to one or two key expressions, in this case value.

I then boil it down to that fact that for the customer the service is a ‘black box’: a guaranteed, fixed-price, repeatable, managed & measured delivery of value.

Or rather this is what it should be, never forget that ITIL is descriptive and that not all of us can do all of it, all at once. If ITIL is maturity-level 100, and you’re at 25; it is not required to reach 100 in one step, but rather use the ITIL guidance to reach 30 (and then 40, 50, …).

See, there is another analogy to explain the use of the ITIL theory in practice.

But, to put the concept of a black-box service into perspective I normally use public transport, particularly the bus (rather than the more commonly used analogy of a restaurant).

When you take the bus, you go to the bus-stop and wait for the bus. Now I keep mentioning ‘bus’ which really is a kind of technology. But, as a user or customer of this service you are perhaps unaware or at least not overly interest in the type of bus: petrol, diesel or natural gas powered, articulated, double-decker, new or old … it doesn’t really matter (you may have a preference, but you wouldn’t not go on a bus because it is not the type you like\want) … black box.

When you get on the bus, you pay. In my area we have smartcards and you pay per ‘zone’, currently $1.45 for 1 zone. Now this is $1.45 every day, unrelated to the price of fuel, the salary of the driver, the depreciation of the bus, the costs of maintenance … fixed price.

The bus will take you to where you want to go (into town in my case), within a certain timeframe. You don’t have to worry about this and can read the paper (or play Angry Birds on your phone as I do) … guaranteed & repeatable.

Sure, the ‘guaranteed’ part is relative: the bus could have an accident, break down or a major traffic jam could delay it, but these are fairly big/high-level risks. All the smaller (technical) risks are covered by the bus company and more-or-less invisible to me as a passenger.

So services do not defer ALL costs, and\or ALL risks, but make them more predictable and higher-level. More importantly, as services support the business in their outcomes, it is the business who is responsible for defining them. 

In my case this is getting to work. Now note that if I arrive late, I cannot blame the bus (or at least not all the time). As a customer it is my responsibility (or accountability really, but more on those two some other time) to select the appropriate service provider and negotiate the required service levels: instead of the bus, I could have driven my car in (faster, but more expensive to park), or taken a taxi (faster, more expensive), my bike (slower and harder to take stuff with me, not to mention my inadequate level of fitness), private helicopter …

Analogy and lesson 1: Customer define the services, but then expect fixed-price, black-box, repeatable and guaranteed delivery.

the ITIL Zealot
March 2013

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

Is your Service Desk a SPOC or a SPOF?

One of ITIL’s benefits is identified as the ‘one language’ to be spoken within IT; and often people indicate this is an objective at the start of a course (I want to learn what this ITIL is I keep hearing about) or the benefit obtained at the end (now I know what the others are talking about). ITIL does introduce a lot of definitions (have a look at the full glossary-of-terms: 55 pages !) and as a good methodology should , it also contains a lot of acronyms. So let’s start with explaining the ones I’ve used in the title:

•    SPOC = Single Point of Contact
•    SPOF = Single Point of Failure

The Service Desk is supposed to be the Single-Point-of-Contact for Users on a day-by-day basic (i.e. for incidents and service requests). Although mistakenly (IMHO, another acronym although not ITIL-specific) the book reference its primary aim not so much to be a SPOC but to restore normal service to users (which is the incident management objective and only part of the service desk’s activities).

The reason is simply (and mostly well-understood and reasonably implemented in your average organisation): instead of letting the Users having to hunt around and find someone in IT who can help him, they can contact the service desk for anything and everything. From there the correct service process and function will be engaged. As such it is not only the single, but also the FIRST point of contact and this makes it very important, if not critical in the perception of service.

Imagine company A with you-beaut IT: the latest-and-greatest in desktops, the latest-and-smallest in laptops, massive fully-redundant internet-pipes ... but no service desk to speak of. When something goes wrong you, the user, has to find an IT person and when you finally do, you’ll get a response like ‘yeah, what do you want ... you touched it didn’t you? ... I don’t have time for that ... I’ll look at it this afternoon, maybe, if I feel like it!’

Company B on the other hand has IT equipment that is a bit longer in the tooth, not as powerful or modern. It does break (occasionally) but if it does you can call the service desk. There your phone-call gets answered within 30 seconds by a friendly voice who tell you that ‘we are aware there are currently some issues with the e-mail service and according to the latest information we’ve received it should be fixed in the next 15 minutes’ (and it is: say what you do – do what you say).

Now, I reckon that when it comes to user satisfaction, company B is going to give company A a run for its money. Not because their IT is better, but their service is (or at least their service desk). This is the role that the service desk plays: in the perception of the value of a service. Hence we need to make sure it is resourced properly and that means not necessarily with junior technicians (who have to do a tour-of-duty on the service desk before they’re allowed to touch a server or a piece of network equipment).

After all, it is the service desk operator which needs to differentiate between user A and user B calling to tell them their e-mail is not working. On the face of it two similar incidents, but with user A screaming down the phone that they are a manager, that it is a disgrace and that they demand someone to fix it ... right now! However, user A doesn’t actually need e-mail that much for their work (it could easily be -temporarily- replaced with phone-calls, faxes or face-to-faces). 

This in contrast to user B, who addresses the service desk a lot politer, almost apologetic for the fact that email is not working and hope they haven’t caused any trouble. User B actually performs their tasks using e-mail (for instance receiving orders from clients).

The service desk not only needs the communication skills to deal with the angry user A, but also the business-skills to understand the relative impact & urgency of both user, the service-knowledge (including SLA and service catalogue) to determine how to respond to this. Any technical skills might help in the initial diagnosis, but so does the knowledge\known error database.

Without these skills and the true service attitude (always remember that without IT most organisations would still exist, but without those organisations most of us wouldn’t have a job!) your service desk may still be a SPOC, but it might very well also be a SPOF. 

OK, perhaps not a single point of failure but certainly the first, visible one. And you only get one chance to make a first impression, and those first impressions are normally what tips the favour in any satisfaction survey.

the ITIL Zealot
July  2012

Customer Satisfaction or User Delight – Take your pick!

I admit I am a sucker for ‘big titles’ which raise more questions than this little blog could possibly answer. Sorry …

But I do want to talk (ok, perhaps rant would be a better description) about this. Let’s start with the fact that many organisations claim to be measuring Customer Satisfaction whereas in effect they are measuring USER Satisfaction. See my blog on Customer vs. User.

Even that is fraud with options and obstacles. Firstly ITIL puts the responsibility for Customer\User Satisfaction (yes, surprise-surprise, ITIL still has some ambiguity) with the Service Desk. Like they have nothing better to do! This then comes down to often nothing more than an automatic e-mail upon the closure of an incident (or the fulfilment of a request). Useful? Perhaps, but you’re likely to get quite biased results, based on whether the user was satisfied or not with the solution. Surely a part of satisfaction, but what about all the other elements of service (in particular when there aren’t any incidents)?

The 'closure-follow-up' is a useful measure as it reflects on the Service Desk (how was your call answered, were you kept informed of progress, did we verify the incident\request was completed to your satisfaction, …). And the Service Desk is the single-point-of-contact for Users and as such the business card of IT and as such THE most important factor in the perception of the value of the service (by the User).

First hypothetical: organisation A has U-beaut (Australian expression for wonderful) IT – the latest and greatest in desktop, the latest and smallest in laptop, huge network pipes, fully redundant … but there is no real Service Desk. The Users have to hunt around for someone in IT and when they finally get hold of someone their response will be along the lines of ‘yeah, what do you want … mmm, you touched it didn’t you … I can’t deal with this … look, I might have a look this afternoon, maybe … 

Organisation B on the other hand has crap IT (excuse my French): the PCs are old, laptops weigh a ton and the network breaks down regularly. But there is a Service Desk and if you call them they answer the phone within 30 seconds, are aware of the incident and provide you with a prognosis of restoration (which turns out to be true: say what you do \ do what you say!). Who do you think (A or B) is going to get the best User Satisfaction? (hint: B, despite the crappy IT)

What’s more, I truly believe most Users accept the fact that services aren’t perfect and can (from time to time) break. It is how we deal with this break\complaints that will truly cement our perception of service value. Imagine you bought a new gadget and after a few days it breaks. You understand that this can happen and take it back to the shop. In (the next) hypothetical, shop A blames you for the fault (‘you touched it!’) and refuses to fix it under warranty. What a bummer, you’ll never go back to that shop. 

Hypothetical B on the other hand apologises profusely, immediately replaces the gadget and offers you some kind of bonus. Wow, wonderful; you will definitely come back to this shop again. Now of course if the gadget keeps breaking this satisfaction will wear thin, but as a one-off the break (and subsequent service) has actually improved the satisfaction.

In hypothetical C the gadget would never break and you would never experience the service of the shop and either will or won’t go back there. This is the case for User Delight over Satisfaction. After all if you go on a business trip and the hotel that you are staying is ‘OK’ you’re not going to rave about it to anyone. The room was OK, the linen clean, the water warm … all OK. In fact you may not even come back to this hotel next time, if another seems to have a better offer. 

On the other hand if the hotel surpasses your expectations (chocolate on the pillow, complimentary massage, …) you’re going to tell everyone and will definitely come back to this place. That’s User Delight! BTW I don’t think this analogy quite holds true has in IT service management we don’t deal with transactional, one-off service, but with long-term relationships.

But back to true Customer Satisfaction. This is the domain of Service Level Management (or perhaps Business Relationship Management, but there is the ambiguity again). In fact as much as Service Level Management is about measurable targets (you can’t manage what you can’t measure) the ultimate result is Customer Satisfaction. The target might be 99.9% availability but the Customer Satisfaction is going to be vastly different if the 0.1% outage is the day before Mother’s Day and you’re a florist, or it is the day afterwards. Who cares about the numbers, as long as the customer is happy\satisfied.

Customer Satisfaction is more important than User Satisfaction (as the Customer is a decision-maker and budget-holder so if they’re not satisfied they’re not going to do business with you anymore). Besides if the Customer does his\her job well, they should ensure User Satisfaction (again, see my blog on the Bermuda triangle of Customer-User-IT).

However, as much as people claim to measure (Customer) satisfaction, it is not really an objective measurement. Imagine an organisation with no seasonal influences or daily differences in demand, just straight 24x7: every minute is as important as the next. In the space of a year this organisation suffers 1 outage of 1 hour. In hypothetical A this outage was 364 days ago and in hypothetical B it was yesterday. For all intends-and-purposes this is the same availability and the same business value, but who do you think will get a higher satisfaction (hint, it’s A!).

In summary, satisfaction (Customer or User) is one of the most valuable measures you can obtain as it truly indicates the value of the service delivered. It is the ultimate goal of service delivery (a customer or user who is satisfied with the value received) but also a very hard measure to objectively obtain.

the ITIL Zealot
May 2012