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.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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 http://www.hus.fi/en/about-hus/Pages/default.aspx

 

 

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ä.

Net promoter score on huono idea

Net promoter score, NPS on uusi tapa yrittää tulkita asiakastyytyväisyysmittausten tuloksia.  Siinä kysytään suosittelisitko palvelua ystävällesi. Skaalana on 0-10 ja näistä 9-10 tulkitaan suosittelijoiksi, 7-8 neutraaleiksi ja 0-6 arvostelijoiksi. NPS saadaan vähentämällä arvostelijoiden prosenttiosuus suosittelijoiden osuudesta.

Mittarissa on monta puutetta. Ensinnäkin se olettaa että asteikon tulkinta on samanlaista kaikkialla. Suomessa meillä on monille tuttu kouluarvosana, eikä ole ollenkaan varmaa kokevatko vastaajat arvon 7 neutraaliksi. Toinen puute on se, että kaava hukkaa paljon informaatiota. Tarkat arvosanat menetetään ja jäljelle jää vain kolme vaihtoehtoa.

Kolmas vika on siinä, että NPS on epästabiili, erityisesti pienillä aineistoilla. Vaikka vastausten keskiarvo on sama, voi NPS vaihdella paljon. Alla olevassa kuvassa molempien jakaumien keskiarvo on sama, mutta NPS on toisella kaksinkertainen. Ei ole lainkaan selvää, kumpi jakaumista olisi ”parempi”. Sen sijaan että kiittelee sinisen aineiston hyvää NPS lukua, pitäisi selvittää miksi siellä on noin paljon huonoja arvosanoja.

nps

Vastaavasti keskiarvo voi vaihdella suuresti, vaikka NPS on sama. Esim 50% NPS arvon saa keskiarvoilla 9,0 ja 7,5.

Neljäs vika on itse kysymyksessä. Se sopii hyvin lomakohteeseen, ihmisillä on tapana suositella lomakohteita toisille. Toisaalta on olemassa palveluja, jotka kaikki tuntevat ja joiden suositteleminen tuntuisi luonnottomalta. Suosittelisitko Alkoa ystävällesi? Olen joskus vastannut tuollaiseen kysymykseen: ei missään tapauksessa, vaikka pidin palvelua erinomaisena.

Palvelun jonkin osan suosittelu tarkoittaa implisiittisesti itse palvelun suosittelua, jolloin se voi sotkea tuloksia. Yksi vastaaja saattaa ajatella, että vaikka kokonaispalvelu oli huono, suosittelisin tätä osaa. Toinen taas ajattelee, että vaikka tämä osa on loistava, en voi suositella koska kokonaispalvelu oli heikkoa.

Mielestäni NPS on vain yksi esimerkki huonoista tutkimusmenetelmistä, joita näkee liian usein. Erilaisten kyselytutkimusten tekeminen on helppoa ja sen takia niitä tekevät ihmiset, jotka eivät ymmärrä mitä ovat tekemässä.  Valitettavasti päättäjät eivät myöskään näytä osaavan erottaa hyvää tutkimusta huonosta. Siksi kai tällainen NPS:n tyyppinen tavara näyttää myyvän.

Miten SLAt saa toimimaan

Eräs vastaaja vastasi äskeisessä pikakyselyssä näin :”minua on harmittanut epäpätevä keskustelu SLA:n hyödyistä ja sen kyvyistä ohjata prosessien priorisointia. Keskustelu on mielestäni sivuraiteella”

Vastaaja on varmasti oikeassa. SLA eli palvelutasosopimus tai -lupaus on hyvä työkalu kun sitä käytetään oikein. Väärin käytettynä siitä sen sijaan voi olla haittaa. Tässä näkemykseni siitä miten SLAt saa toimimaan oikein.

SLA toimii silloin kun:

  1. asiakas tietää tarkalleen mitä haluaa ja on valmis maksamaan siitä
  2. toimittaja kykenee säätämään palvelun halutulle tasolle

Ensimmäinen edellytys on siis, että puhutaan melko vakiintuneesta palvelusta, joka on kuvattu täsmällisesti. Esimerkiksi matkatoimiston käyttämä hotelliluokitus on aika hyvä esimerkki toimivasta SLAsta palveluissa. Viiden tähden hotelleja haluavat matkailijat ovat matkatoimiston kannalta ihanneasiakkaita, eikä heille kannata tuottaa pettymystä.

Asiakkaan vaatimukset

It-palveluissa ensimmäinen pulma tulee siitä, että asiakas ei osaa sanoa mitä tarvitsee. Tai tarkemmin sanottuna: asiakas ei osaa sanoa riittävän tarkasti mitä haluaa. Palvelusopimuksen neuvottelijat eivät ehkä itse käytä palveluja, eivätkä osaa tarkalleen määritellä vaatimuksia. Toinen pulma tulee siitä, että palvelujen sisältö muuttuu kaiken aikaa. Asiakas ei voi tietää omia tulevia tarpeitaan kun palvelun sisältö muuttuu ja it-palvelut usein muuttuvat jatkuvasti.

Huono esimerkki SLAsta on käytettävyysprosentti. Äskeisen SuperBowl ottelun aikana oli puolen tunnin sähkökatko. Jos katko oli ainoa, käytettävyys oli silti vuositasolla 99,99% ja kuukausitasollakin 99,9%. Ysien määrä ei auta, jos palvelu pettää kriittisellä hetkellä. Jotkut tarjoavat vastaukseksi 100%  palvelutasovaatimusta, mutta se voi olla usein turhaa ja kallista.

Pitäisikö palvelutaso aina mitata asiakkaan hyötyjen kautta kuten Stuart Rance esitti aiemmin. Mielestäni kyllä jos mahdollista, mutta usein se lienee mahdotonta. Lisäksi meillä Suomessa hyvin suuri osa it-palveluista on ulkoistettuja, eikä palvelun tuottajalla ole edes suoraa yhteyttä palvelua hyödyntävään liiketoimintaan.

Toimittajan kypsyys

Palvelutason säätäminen edellyttää paljon toimittajalta. Toimittajalla on oltava hyvä hallinta palveluista ja toimittajan tulee kyetä säätämään palvelutasoa. Palvelusopimusten tulee vastata täsmälleen sitä, mitä tuotetaan. Häiriötekijöiden syyt pitää tuntea ja niihin pitää voida vaikuttaa.

Priorisoinnin pitää toimia hyvin ja yli prosessirajojen. Henkilöstön pitää tietää missä järjestyksessä työt tehdään.  Osa palveluntuottajista varmasti pystyy tähän, mutta se ei tarkoita sitä, että palvelu onnistuisi sen käyttäjien kannalta. Palvelun tuottajan on hyvin vaikea tietää esimerkiksi asioiden todellisia prioriteetteja, jos he toimivat etäällä palvelun käyttäjistä.

Vaihda toimittajaa, mutta katso ensiksi peiliin  

Sanktiot koetaan tärkeiksi, koska ilman niitä palvelu ei toimi. Sanktiot ovat kuitenkin huono väline yhteistyössä. Parempi vaihtoehto olisi vaihtaa toimittajaa kunnes löytyy sellainen, joka palvelee hyvin ilmankin sanktioita.

Mikäli palvelussa on ongelmia, pitää selvittää ongelmien syyt. Palvelun tuottaja on hyvä syntipukki omille virheille. Palvelussa voi myös olla rakenteellisia ongelmia, jotka aiheuttavat ongelmia palveluntuottajasta riippumatta.

Helsingin Sanomien mielipidekirjoituksessa toivottiin VR:lle kilpailua ja kirjoittajan mukaan sanktioilla saadaan paremmin toimiva junaliikenne. Mielestäni toive on tuulesta temmattu. Helsingin aseman ohjausjärjestelmä ei tottele sanktioita sen enempää kuin lumipyrytkään. VR:n pilkkomisen seurauksena kokonaisvastuu on kadonnut ja sama pätee moniin it-palveluihin.

Kipupisteet

Pink Elephantin vetäjä David Ratcliffe esitti viime viikolla hyvän kysymyksen twitterissä ja päätin kopioida sen helmikuun pikakyselyksi:  What has been your first big ITSM pain point so far in 2013? Suomeksi kysymykseni on siis vapaasti käännettynä. Mikä asia on harmittanut eniten it-palveluhallinnassa alkaneen vuoden aikana?

Valitsin tämän kysymyksen, koska minun oli itse helppo vastata tähän. Ilmeisesti kaikilla ei ollut vastaavia kokemuksia, koska vastauksia tuli aika vähän, 28 kpl.

Yleisin aihe oli huono palvelun laatu, niitä oli melkein kolmasosa. Esimerkkejä olivat palvelun hitaus, toimimattomuus ja epämääräisyys.

Ulkoisen palveluntuottajan heikko laatu toiminnassaan; suunnattomasti virheitä, viesteihin ei vastata,  ei tehdä mitä sovitaan vaan tehdään ihan jotain muuta,….

Kakkosena tuli johto, eli johdon kyvyttömyys päättää asioista tai ohjata toimintaa.

Minua on harmittanut ylemmän johdon ymmärryksen niukkuus yhä siitä miten olennainen heidän rooli on muutoksen jalkauttamisessa.

Seuraavat aiheet olivat prosessit

Palveluprosesseja ei ole saatu kaikilta osin lanseerattua päivittäiseen toimintaan ja prosessien kehittäminen on jatkuvaa – muutokset samoin.

ja työkalut, jotka eivät toimi halutulla tavalla.

Käytössä olevan ITSM -työkalun sopimattomuus meidän prosesseihin.

Vastaukset olisi toki voinut luokitella toisinkin, työkalut, johto, palvelun laatu liittyvät monessa mielessä prosesseihin ja niiden soveltamisen vaikeuteen.

Omat vastaukseni oli tämä:

Yritän tehdä yhteistyötä muualla asuvan asiakkaan kanssa. Kokemusteni mukaan yhdistelmä Google Hangout ja Google Docs on loistava. Siinä joukko ihmisiä voi työstää samaa dokumenttia ja keskustella videoneuvottelussa yhtä aikaa. Valitettavasti yhteistyö kaatui sisäisen IT.n luomiin esteisiin. Tilalle tarjottiin työkalu, joka ei toiminut. Tietoturvan perusteella estetään tuottavuuden nostaminen. Ehkä tämäkin on palvelun laatua.

Hyvä kysymys on sitten se, mikä ei noussut esiin?

 

Asiakastuki on entistä tärkeämpää

Tämä 20 min video on mielestäni hyvä. Siinä Richard White kertoo miksi he järjestivät UserConf -tilaisuuden. Hän etsi konferenssia, jossa puhuttaisiin modernista asiakastuesta. Hän kertoi löytäneensä kahden tyyppisiä tilaisuuksia:

1) ITSM konferensseja, joissa ihmisillä on pakkomielle ITIListä, mutta joiden käsitys asiakastuesta on outo. (No hän ei ollut Kalastajatorpalla, mutta kuvaus sopii hyvin itSMF UK:n konferenssiin.)

2) Call center tilaisuuksia, joissa soitetaan vanhaa ”Puhelusi on tärkeä meille” -levyä.

Molemmat tilaisuudet kuvaavat menneisyyttä. Uusi asiakastuki on erilaista, siinä

  • henkilökunta on erittäin osaavaa
  • tuki toimii kaikilla medioilla
  • tuotteen viat ratkaistaan tunneissa, ei kuukausissa
  • jokainen asiakaskohtaaminen on mahdollisuus

Asiakastuen sijasta pitää puhua asiakaista huolehtimisesta (customer care). Poikkeuksellinen asiakaspalvelu ei ole mitään uutta,  mutta aikaisemmin se on liitetty ylellisyystuotteisiin. Nyt maailma on muuttunut, internet on luonut itsepalveluun perustuvan liiketoimintamallin. Yksinkertaiset asiat hoidetaan itsepalvelulla ja asiakaspalvelua tarvitaan vain vaikeimissa tapauksissa.

Perinteinen myyntimalli korosti kaupan merkitystä, mutta nykyään yhä useammin myydään jatkuvaa palvelua, jossa asiakkaiden pysyvyys ratkaisee. Tässä ei ole mitään uutta mutta kaikki eivät ole vielä tajunneet asiakastuen merkitystä myynnille. Jokainen asiakaskontakti on potentiaalinen myyntitilanne. Siksi joissakin tapauksissa myynti on asiakastuen kakkostaso!

Usein korostetaan että huono asiakaspalvelu on yleisin syy asiakkaan menettämiseen, mutta tuoteen laatu on toiseksi tärkein syy. Asiakastuen pitää olla osa tuotetta.

%d bloggers like this: