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

Service Management basics

Happy New Year

Somehow I thought I would be able to write my blogs ahead, and then release them fortnightly (or at least two-a-month). Reality has taken over and I now find myself in January without any pre-prepared blogs. So, with this in mind and as we’re starting a new year, I thought perhaps I should go back to the basics.

As an ITIL zealot, I of course am strongly inclined to see ITIL as the one true way of ‘implementing’ service management. But I am certainly not that myopic not to recognise that there are some excellent ‘other’ frameworks around which offer complimentary and sometimes even superior advice (I am particular enarmoured with COBIT5 and may devote a future blog to that).

But more than any specific methodology I find that recently I am spending more time (in ITIL training etc.) explaining to people the basic concept of Service Management (and then how ITIL fits in). So, the basic concept of service management is the management of services (yes, sometimes things are THAT simple). A service, in turn, is the value we deliver to the business, which is not related to any specific technology used (but rather the utility and warranty, which are a great set of concepts, although ITIL could have used them better and more consistent).

So, my first and possibly most basic teaching is that we (i.e. all ‘IT-people’) need to focus on our deliverable\value rather than our delivery\technology. This is most evident in a process like Incident Management that deals with break-fix. ITIL provides a great objective-statement for this process which is ‘to restore normal service as quickly as possible, and minimise impact on the business’.

I always highlight three key parts in this statement, the first being ‘restore’. Incident Management is not about fixing, improving or anything permanent\long-term, but merely about restoring the normal\working situation, sometimes using workarounds (the equivalent of taking an aspirin …). The second highlighted part is ‘as quickly as possible’, which then leads to the priority-setting (impact and urgency), which is driven by the customer, business or at least the service targets of the SLA.

The last part of the Incident Management objective that is of importance is ‘minimising impact to the business’, which brings us back to the core of service management: delivering value. If a user can’t email, then it is important of us to restore this service (and for future purpose perhaps do a root cause analysis). But of immediate importance is the business process which was trying to communicate (the value), something that perhaps can be achieved otherwise (print & fax, phone, …). A good service desk agent will think with the user, about the business and not restrict themselves to the service levels in place and/or the technology used.

Once you grasp that the basic meaning of a service is the value delivered, then the next\second basic concept is that of the ‘management’ part: the value has to be delivered repeatable & guaranteed. This is where ITIL (or your favourite methodology) plays its part as it provides the structure that allows providers to deliver services repeatable, manageable & guaranteed. 

In ITIL this is done through the processes which provide ‘structured activities’. This is why a good methodology is also known as ‘commons sense, written down’ as those activities are common sense and most people would do them anyway, most of the time (I sometimes joke that there are yet undiscovered tribes in the amazon who are using Incident Management). The structure of a process makes sure that everyone does the activities, all of the time and thus establishes repeatability. By documenting a process (procedure manuals, work instructions etc.) and measuring activities (and outcomes) we make the delivery manageable, repeatable & guaranteed.

But … remember that it was not about the delivery, and thus not about the process, but rather the outcome\value\service that is being delivered. Processes\ITIL are merely a means to an end (even though sometimes zealots like myself get lost in the intricacies of the means, thus forgetting the end)!

Focusing too much on process is the equivalent of declaring the operation a success, even though the patient has died! (but look at the stitching ... textbook).

So, these are the basics of Service Management: it is about delivering value in a repeatable & guaranteed way. Ultimately (or ideally) a service is a fixed-price, blackbox ‘thing’: as a user\customer I don’t care how it happens, as long as I get the value, every time I need it!

Best wishes for 2013.

the ITIL Zealot
January 2013

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