Trust is the solution

It is a common practice to measure incident resolution times and have SLA limits for different priorities. For example, a typical SLA can state that 90% of priority level 2 incidents must be resolved within 8 business hours. One complication is that sometimes resolution must wait for some information or third party act. Usually this waiting time is subtracted from the resolution time which means that the actual resolution time can be anything but be still within the SLA limit.

Another problem is the priority. It is hard to define the right priority and sometimes there is a need to change the priority as there is more information available concerning the nature of the incident. There was recently a discussion on the subject of changing priority where I commented that I consider the whole concept to be a bad ITIL practice. A few commentators disagreed. One person wrote:

… I very much disagree regarding ”bad practice”. Without a measurement for timing – and logically, the timing to resolve something more damaging would be shorter – one has only chaos and is at the mercy of whoever decides timing was not what it should have been.

 In this article, I will explain the reasons why I consider it as a bad ITIL practice and what would be a better practice. The above comment is basically right; it makes sense to measure timing and it is true that important matters should be resolved faster. I disagree that it leads to chaos if customers can decide what is the right timing. But this is not the real problem, the core problem lies in the SLA connection. When resolution times are set as a SLA target the timing easily becomes dominant and it will override common sense and customer value.

Any metric can be harmful if it used incorrectly. Usually management wants to have numbers and easily defined targets but metrics can be toxic.

Road side speed measurements do not show high speeds, if they did, some drivers would try to get record numbers and the safety measure would become a source of danger.

Firstly, the measurements are very easy to manipulate. If you haven’t seen cases where all SLA’s are met but customers are quite dissatisfied, you do not know much about real life in ITSM. It is far too easy to play with the measurements as so many things are hard to define. Here are some techniques:

  • ask difficult questions from the customer and stop the clock while they try to answer the questions
  • give low priority to difficult cases, or change the priority if the deadline approaches
  • classify more automatically generated events as incidents and solve them fast

All these tricks will help to fulfill the SLA promise without providing any value to the customer.

The second major problem is the setting of priorities. It is difficult and usually there are simple rules, which give a ticket a priority based on the affected service. The given priorities do not necessarily reflect the true business value related to the case. One thing is sure, any mechanical, automatic priority system will fail.

Here is an example, I’m sure many have seen similar cases:

IT service provider ITSP has a culture of fast responses and close cooperation with their customers. They know when they need to drop everything and jump to prevent a potential failure. They have processes and use a ticketing system to make sure that things are not forgotten, but they are not orthodox about it and do not always create tickets. They have no SLA’s.

 One day ITSP management decides to implement best practices. All incidents need to be handled following SLA requirements and it is a severe error to let SLA times slip.

 So, when next time there’s a potential failure, the IT staff concentrate on following orders and refrain from jumping to prevent the failure. The staff closes a group of minor tickets which are close to breaching the SLA limit before they start working on the major failure and resolve it just within the SLA.

 Everything is ok, there has been no SLA breaches but the customer is mad because they could see that the IT people were closing insignificant tickets while their business ground to halt due to a major IT failure which was waiting.

The solution to the priority and SLA problem is simple; trust. If you can trust your service provider, you do not need to set SLA penalties. If you can trust your staff to make good decisions, you do not need rigid prioritization.

This far from easy, trust needs to be earned and it is easy to lose it. On the other hand, it is very rewarding and it is good for business.


You don’t improve service with mistakes.

The customer wanted to return a tire. Never mind that the Nordstrom department-store chain sells upscale clothing, not automotive parts. According to company lore, the clerk accepted the tire because that’s what the customer wanted. Newsweek 1989

I heard the Nordstrom story years ago (it is probably just a legend, there are many variations about it). Consultant have been telling stories of great service recoveries. At some point the consultants made the next conclusion: If you are perfect, customers don’t notice you. If you make basic mistakes and recover well, they can be delighted! Stuart Rance said this in his presentation few days ago and I commented that I disagree with the idea and this blog is an explanation for my comment.

Of course a good recovery is nice and may lead to short term satisfaction but solid, reliable good service is better.  I specifically disagree with the first part of the sentence and the implied idea that a faulty but well recovered service might be better. Reliability or service warranty is really important and I doubt if people stop appreciating it.

I have worked from home for almost ten years. During that time, I don’t remember a single internet service outage which would have prevented me from working. I may have needed to use my phone as a WLAN provider for a short while once or twice during these years but that backup comes from the same telco. Reading about the difficulties other people have helps me to appreciate this reliability and I definitely don’t wish any basic mistakes to happen with the service.

Some people (including me) have argued that it is not possible to delight customers with ordinary, basic services; that delighting belongs to luxury services. I disagree with my earlier opinions. An ordinary service experience can be delightful if it is well done. As always, the customer expectations are important.

We moved recently and we hired a moving company to do most of the work. I went to pick up extra 20 boxes early so that we would have time pack difficult and time consuming items like fragile glassware. The transaction went like this. I reported at their office that I had arrived to pick up the boxes. They checked the order and printed out a document for their warehouse. Then I drove to the loading bay. The guy was there already waiting with my boxes, then he came down and looked at my car and figured out how to fit the boxes. Then he loaded them in the car and I just watched. It was a smooth operation and the service clearly exceeded my expectations. I had expected to need to wait for the delivery and that I would have to pack the boxes myself.

A simple, well operated, efficient, and seamless service operation is beautiful, just like good design in an object. Of course not all customers appreciate beauty and good design as sometimes it is a matter of taste; but most people do appreciate good service even if they do not understand the hard work behind it.

So, what if nobody appreciates your beautiful service. One reason could be that your service is not as perfect as you think. There might be some elements which are not so well planned. Remember that the service provider’s view of the service is different from the customer’s. You need to consider the customer experience. (Here you need to understand that the people who use your service are your real customers, it is not relevant who pays for the service. If the customers don’t like your service and they walk away, the money will follow.) You need to study the customer journey to your service from the beginning to the end. Details are important. The ITIL Practitioner gives good advice on this: Data is not a substitute for direct observation, page 20.

There is one important element in the Nordstrom story and it is the right to make decisions at the customer interface. It was the clerk who decided to refund the tires. Don’t make recovery a management decision, give your 1st line staff to right to choose the right compensation.


















Eri palvelukanavien yhteispeli

Tein kesällä vahinkoilmoituksen OP-Pohjolalle. Kännykkä oli päässyt meriveteen ja lakannut toimimasta. Aurinkolasit päätyivät samalla kertaa meren pohjaan. Vastausta ei kuulunut. Lopulta soitin ja tiedustelin asiaa. Kohtuullisen jonotuksen jälkeen minulle vastattiin ja sain ohjeet, miten toimia. Virkailija pahoitteli, ettei sähköistä ilmoitusta oltu käsitelty ruuhkan takia.

Toimin ohjeiden mukaisesti ja täydensin ilmoitusta kuiteilla kännykän vaihdosta ja uusien aurinkolasien ostosta. Mitään vastausta ei tullut, eivätkä luvatut korvaukset ilmestyneet pankkitilille. Soitin uudestaan. Nyt en jaksanut jonottaa vaan tilasin takaisinsoiton. Se tuli kohtuullisen nopeasti, mutta olin juuri silloin katveessa. Virkailija jätti ääniviestin ja lupasi soittaa uudestaan. Sen hän tekikin. Kerroin pulman, hän tarkisti hakemuksen ja sanoi sen olevan ok. Valitteli taas kiirettä, mutta käsitteli asian saman tien ja laittoi rahat maksuun. Ne olivat tilillä seuraavana päivänä.

Periaatteessa ihan ok palvelutapahtuma, mutta siinä oli mielestäni kaksi aika tavallista virhettä. Oli ilmeistä, että OP-Pohjola suosii puhelinasiakkaita. Puhelimessa asiat hoituvat, sähköisesti eivät. Tämä vastaa aika hyvin aiempia kokemuksiani Tapiolan kanssa, joten ajattelin kirjoittaa ilmiöstä.

Jos sähköinen asiointi olisi toiminut, olisi vältetty kolme puhelua. Toimintaohjeita ei olisi tarvinnut antaa puhelimessa, vaan ne olisi voinut kopioida ohjekirjastosta. Asian käsittelyyn olisi kulunut vain murto-osa nyt kuluneesta ajasta. Sama henkilö olisi voinut käsitellä arviolta viisi asiakasta siinä ajassa mitä heiltä kului kanssani.

Oletan, että kyse on siitä, että OP-Pohjolan johto seuraa palvelumittareita, joissa puhelutilastoilla on suuri paino ja siksi henkilökunta keskittyy tuottamaan mahdollisimman hyvää puhelinpalvelua. Perusteluna on varmaankin se, että valtaosa asiakkaista käyttää puhelinpalvelua mieluummin. Tämä argumentti ei toimi. Todellisuudessa ihmiset ovat valmiita muuttamaan tapojaan nopeasti, jos uusi tapa on parempi. Muistan hyvin, kuinka hauskaa oli ohittaa jono lentokentällä, kun ryhtyi käyttämään itsepalvelua perinteisen palvelutiskin sijaan. Valitettavasti muutkin oppivat sen nopeasti.

Vakuutusyhtiöiden pitäisi tarjota sähköisillä kanavilla nopeampaa palvelua. Sähköiset hakemukset pitäisi käsitellä 15 minuutissa, johdon pitäisi olla kiinnostunut sähköisten kanavien suosiosta ja puhelinkanavan painoarvoa pitäisi pudottaa.

Vakuutusyhtiöillä näyttää myös olevan taipumus tehdä sähköisestä asioinnista mahdollisimman hankalaa. Viestit pitää tehdä heidän suljetun verkkonsa kautta ja kaikki vastaukset tulevat myös samaa reittiä. Ymmärrän toki, että luottamuksellisen tiedon lähettäminen sähköpostilla sisältää riskejä, mutta valtaosa viesteistä on täysin epäluottamuksellisia. On typerää lähettää asiakkaalle sähköposti, jossa kerrotaan, että suljettuun postilaatikkoon on tullut (tyhjänpäiväinen) viesti. Sähköpostissa pitäisi kertoa lähetetyn viestin sisältö.

Vastaavasti sähköiseen viestintään on helppo asettaa turhia rajoituksia ja ehtoja, joita puhelinpalvelussa ei sovelleta. Kyse lienee kaikkiaan siitä, että erilaiset keskijohdon jäsenet pääsevät pätemään järjestelmän määrityksissä, ja asiakasnäkökulma unohtuu.

ITSM and surgery

Kuva1I had my right eye operated last week. It was a new procedure where they remove some tissue from behind the eye and the surgeon operates through the eye. Scary stuff, especially as I was wide awake throughout the procedure. After the operation I have been thinking of the similarities of surgery and ITSM.

It is clear that surgery is a service, I receive the value (if the operation is successful) and the staff is paid to do the work. I have criticized the ITIL service definition as it requires a service to remove the specific risks. That doesn’t really work in IT and in my case. All real risk is mine, or hopefully was.

It is quite difficult to assess the value of the operation. Without it I might have lost my sight from the eye but this would have happened gradually. It will take time to know if this operation was successful. Of course if it is a failure, I will know sooner. (Here in Finland it is not possible to make money by suing the doctor.)

I am a customer, the operation costs me 107.30 € but that is not the real cost of the operation. I am a user in the sense that I do not make the contract between the hospital and the city of Helsinki who pays the rest. Neither of these terms really fit in this case.

There is no service catalog for me, I was told that I must undergo this operation and this procedure is new but less risky than the old option. Actually this was the first week when they started doing this procedure, which has been developed in the USA. The original inventor was still present monitoring the operation and assessing the results. I don’t fully understand what was done and what are the risks. There is no SLA. Of course I would like to have a promise of 100% success but it is not possible.

The hospital has processes for managing patients.  They seem fairly efficient but they are not very relevant to me. The service part is not very important. The surgeons are not very good at customer service, they are interested in my eye, not me. But that is ok, the only thing what matters to me also is the procedure itself.  Customer satisfaction is not a good concept in this case, it is quite difficult to be very satisfied with this type of operation. I still need to apply drops to my eye more than 20 times a day which irritates the eye and there was some bleeding which makes the eye a bit cloudy. It should become clear soon and the number of drops needed is going down.

Somehow I think that the ITSM concepts miss something which is highly important. It requires a lot of trust to let someone operate through your eye. What I want is that the team doing the operation is competent, motivated and professional. Process metrics are not relevant. In this case I know that the general level of health care in Finland is good and this Helsinki University hospital is the best in the country. Trusting them was not difficult for me. Providing relevant metrics would be difficult. The other hospitals in the country send their most difficult cases here

I think this is what the business also wants from the IT provider. There are technical areas where the business decision makers don’t understand the details and cannot really estimate the risks. In serious matters they should be able to trust their IT providers to be competent, motivated and professional.


Here is a bit more detail information in case you are interested. My disease is glaucoma, it has no symptoms in the early stages but in the long run it will damage the optical nerve. The usual treatment is medication but it does not work always and it is not a cure. It is a good idea to visit an ophthalmologist regularly. The hospital was



Service Deskin laskutus

Sain tällaisen kysymyksen ja päätin vastata siihen blogilla: ”Mitä etuja tai riskejä näet Service Deskin tikettipohjaisessa tai loppukäyttäjämääräisessä laskutuksessa?” Oletan että kyseessä on ulkoistetun service deskin laskutusvaihtoehdot. Joko laskutetaan kirjattujen tikettien mukaan, tai käytössä on kiinteä kuukausilasku, joka perustuu käyttäjien lukumäärään.

Pidin juuri TIVI Service Desk-päivillä esityksen: ”Miten Service Desk tuottaa arvoa?”, jossa käsittelin aihetta. On tärkeä ymmärtää, miten IT:n tuottama arvo muodostuu. Arvoa syntyy kun asiakas käyttää tietotekniikkaa omassa työssään, luodakseen organisaation tuottamaa arvoa. Joskus tietotekniikka voi tuottaa suoraan arvoa, mutta yleensä se on mukana muodostamassa sitä. Erilaiset pulmatilanteet vähentävät tätä arvon tuottamista, ja service deskin tehtävänä on minimoida arvon tuottamisen menetys.

Nykyaikainen deski toimii monien kanavien kautta. Itsepalvelu, tietopankki ja keskusteluforumit ovat esimerkkejä tukikanavista, jotka eivät tuota tikettejä. Monet tutkimukset ovat osoittaneet, että service desk on melko harvoin asiakkaitten ensisijainen tukivaihtoehto. Ihmiset etsivät tietoa, kysyvät kavereilta ja pääkäyttäjiltä, ennekuin he ottavat yhteyttä tukeen. Hyvä service desk toimii kaikilla kanavilla ja pyrkii minimoimaan asiakkaitten menettämän työajan.

Ajatellaan esimerkiksi, että käyttäjiä on 10.000 ja yhden yhteydenoton hinta on 50€ ja jokainen käyttäjä on keskimäärin kerran kuukaudessa yhteydessä deskiin. Tuen hinta voisi silloin olla joko 500.000€ per kk tai 50€ per tiketti, jolloin kokonaisveloitus olisi kummallakin tavalla sama.

Kuvitellaan, että service deskissä havaitaan, että jokin asia, vaikka epäselvä ohje, aiheuttaa 2.000 yhteydenottoa vuodessa. Tikettipohjaisessa laskutuksessa tämä tarkoittaisi 100.000€ laskutusta vuodessa. Tikettipohjaisesti laskuttavan service deskin kannalta olisi järjetöntä pyrkiä korjaamaan yhteydenottojen aiheuttajaa. Toisaalta jokainen yhteydenotto todennäköisesti edustaa keskimäärin puolen tunnin työmäärää, kun henkilö on yrittänyt selvittää asiaa itse ja mahdollisesti kysynyt kollegoiltaan. Menetetty työaika olisi siis asiakkaalle 1.000 tuntia vuodessa ja siitä aiheutuisi vielä 100.000€ lisälasku.

Kiinteän kuukausilaskutuksen ongelma on taas se, että service deskin kannattaa minimoida asiakkaiden yhteydenottoja kaikin tavoin. Valitettavasti helpoin tapa on tarjota huonoa palvelua. Pitkät jonotusajat, ärsyttävä jonotusmusiikki, töykeä palvelu, osaamattomat työntekijät jne. ovat valitettavan tuttuja keinoja yhteydenottojen minimointiin.

Kummassakin laskutustavassa on huonot puolensa, mutta mielestäni tikettipohjainen laskutus on ehdottomasti kelvoton vaihtoehto. Se mittaa ainoastaan yhteydenottoja eli aktiviteetteja, ei arvoa. Käyttäjämääriin perustuva laskutus mahdollistaa service deskille pyrkimyksen tuottaa aidosti arvoa.

Suosittelisin kuitenkin service deskin ottamista omaan organisaatioon. Tässä esimerkiksi menestystarina, jossa onnistuttiin tekemään samalla kustannuksella parempi deski.

Where is the customer?

Imagine that you come to a hotel and find a Service Desk where a cheerful person assures you that if there is any incident with your room, one of the service specialists will start fixing it within twenty minutes. Behind her, you can se some plumbers, electricians and carpenters ready with their tools, waiting for the next incident. Wouldn’t you want to find another hotel?

The early years of computing were difficult, technology was new and unreliable. It was understandable that incident management was important. But it is a bit silly that customer service is still missing from current ITSM or that it is so technology centric.

This technology centric view of service can be seen in graphs that describe the support processes. In most cases that I have seen, there is no customer service and actually no customer. It is far more likely to find a CMDB or a service catalog in the center of the picture than a customer. The same thinking seems to carry over from ITIL to all other frameworks, standards and methods. Customer service is seen as the restoration of service after an incident.

The technology centric thinking comes with a price. A lot of effort is lost. Incidents need to be connected to the relevant configuration items and services. Many of my customers have configuration management systems and service catalogs but the logging of incidents with service and configuration information provides no value. My major subject in university was statistics and when I started ITSM consulting I was thrilled that I could start analyzing incident data and find valuable information for my customers. That has never happened. Yes, I have analyzed incident data a few times but every time the data has proven to be rubbish. Garbage in, garbage out is a good rule in statistics.

The ITSM thinking should put the customer in the middle and ask the question how does this process or value stream produce value to the customer. I think that the customer centric framework for ITSM would look completely different.

Parempi laatu, pienemmät kustannukset

Turhan työn poistaminen on avain laadun kehittämiseen kustannuksia vähentämällä. Olen koonnut tähän joukon ideoita, mistä voit löytää hyviä kohteita turhan työn vähentämiselle. Nämä ovat ideoita ja niiden soveltaminen pitää tehdä harkiten. Organisaatiosta varmaan löytyy henkilöitä, jotka vastustavat näitä ehdotuksia. Pyydä vastustajia esittämään saavutetut hyödyt ja tarkista kaikkien osapuolten näkemys. Hyvin toimivia käytäntöjä ei tietenkään kannata purkaa, jos ne toimivat hyvin kaikkien osapuolten mielestä. Asiakkaan mielipide on aina tärkeä.

  1. Unohda palveluluettelo, jos se ei tunnu toimivan. Olen nähnyt lähinnä vain huonoja ja hyödyttömiä palveluluetteloja, joita puolustavat vain niiden kehittäjät. Kaikkea IT-toimintaa ei tarvitse kuvata palveluna. Monissa tapauksissa liiketoiminta ja asiakkaat tekevät yhdessä asioita, ja IT-väen tehtävänä on tarjota asiantuntemusta, osaamista ja tekemistä yhteisten tavoitteiden eteen. Yhteistyö ja palvelu ovat eri asioita.
  2. Unohda SLAt. Keinotekoiset palvelutasot eivät takaa laadukasta palvelua, mutta työllistävät paljon. Kaikkea ei voi mitata hyvin ja huonot mittarit ovat turhia.
  3. Unohda CMDB. Sen rakentaminen ja ylläpitäminen on työlästä. Oletko varma, että siitä saadaan todellista hyötyä. On mahdollista, että CMDB:tä ylläpidetään, koska johto on niin määrännyt mutta kaikki tietävät, ettei sen tietoihin voi luottaa.
  4. Poista turhat tiketit. Automaattivalvonnan hälytyksistä on turha avata tikettejä. Asiat pitää hoitaa mahdollisimman vähillä vaiheilla. Tiketin avaaminen ja sulkeminen ovat turhia työvaiheita.
  5. Poista turhat kentät tiketeistä. Keskity olennaiseen. Palveluluettelon ja CMDB:n poistaminen auttaa, mutta vaikka et poistaisi niitä, on silti turhaa kytkeä kaikkia ongelmia johonkin tiettyyn palveluun tai konfiguraation osaan. Usein niiden määrittely on vaikeaa tai mahdotonta. Pakolliset luokittelut tuottavat roskatietoa.
  6. Unohda turhat prosessit. Prosessi on hyvä apuväline toistuvien rutiinien pyörittämiseen, mutta se ei sovellu kaikkeen tekemiseen.
  7. Unohda turhat mittarit. Prosessiajattelu luo helposti paljon prosessimittareita, joilla ei ole oikeasti mitään järjellistä käyttöä. Älä mittaa aktiviteetteja ja älä ainakaan aseta niille tavoitteita. Keskity tuloksiin, ei puuhasteluun.
  8. Rakenna asiakkaille palvelupisteitä, joissa heitä autetaan tietotekniikan kanssa. Yksi vierailu voi ratkaista monta ongelmaa ja säästää aikaa sekä asiakkailta, että asiakastuelta.
  9. Ole mukana sosiaalisessa mediassa, jos asiakkaasi ovat siellä. Yritä luoda keskusteluforumeita, joissa asiakkaat voivat keskustella palveluihin liittyvistä asioista. Yksi hyvä keskustelu voi ratkaista monen asiakkaan pulman.
  10. Kuuntele asiakkaiden mielipiteitä, mutta älä kiusaa heitä turhilla ja huonoilla kyselyillä.
%d bloggers like this: