Odotusten hallinta

Hyviin käytäntöihin kuuluu kuunnella asiakasta ja usein se toteutetaan lähettämällä kysely. Sen perusteella sitten saadaan vastauksia, että asteikolla 1–5 tuohon ollaan tyytyväisiä tasolla 3,72 mutta tämä on vähän kuralla arvosanalla 2,89. Kyselyjen tilastollinen uskottavuus vain on usein koetuksella sen takia, että otanta harvoin täyttää tilastotieteen hyviä käytäntöjä. Tähän onkin helppo vedota: Kun jokin näyttäisi olevan pahan kerran kuralla, tilastoharha on oiva puolustautumiskeino.

Suorasanaiset kommentit kertovat usein enemmän. Mutta. Kun niitä luetaan, usein päällimmäiseksi tunteeksi jää epäusko: Onko kommentoitu kyseessä olevia palveluja lainkaan? Tämä on usein indikaatio siitä, että odotusten hallinnassa on epäonnistuttu: Käyttäjäkunta odottaa palvelulta jotain sellaista, jota ei ole edes ajateltu tarjottavan.

Usein esiin nousevia tyytymättömyyden aiheita ovat esimerkiksi

• Service Desk ei palvele silloin, kun on tarve, eli palvelutoimittaja on huono. (Ei ole sovittu, että SD palvelisi kuin ns. toimistoaikana.)
• Yritin käyttää järjestelmää, mutta se ei ollut päällä, eli palvelutoimittaja on huono. (Oli menossa normaali ylläpitokatko, josta käyttäjä ei ollut tietoinen.)
• Minulla oli pulma, mutta apua tarjosi vain englantia puhuva miekkonen, eli palvelutoimittaja on huono. (Aivan, työnantajasi halusi, että tuki tarjotaan suotuisan kustannustason maasta.)
• Läppärini ei kykene tulostamaan lähimmälle printterille, ja apua on luvassa vasta ylihuomenna, eli palvelutoimittaja on huono. (Häiriönhallinnan prioriteeteissa yksittäisen käyttäjän ongelmat jäävät usein alimmalle prioriteetille. Ylihuomenna saattaa peräti olla ylipalvelua, koska SLA sallii neljän päivän ratkaisuajan.)

Valituksiin ei kuitenkaan pidä suhtautua sillä perinteisellä tavalla, että käyttäjät ne nyt ovat vähän tyhmiä. Valitukset ovat osapuilleen halvin tapa tehdä markkinatutkimusta, ja ne aika usein heijastavat käyttäjäkunnan todellisia tarpeita.

Palveluille, palveluajoille, palvelutasoille ja sellaisille pitää kuitenkin aina olla rajansa, ja rajanveto on yleensä kompromissi kustannusten ja tuotetun arvon välillä. Oleellisen tärkeää on tiedottaa palvelusopimusten sisällöstä ja niihin liittyvistä rajauksista käyttäjäkunnalle. Näin saadaan odotukset paremmin vastaamaan sitä, mitä on sovittu. Tällä tavoin saadaan parannetuksi käyttäjäkyselyjen tilastollista merkittävyyttä ja leikatuksi väärinkäsityksistä kumpuavaa tyytymättömyyttä.

Häiriönhallinnan prioriteetit ovat palveluaikojen lisäksi yksi merkittävä kipupiste. Taustalla oleva sopimus voi olla hyvinkin monimutkainen. Siitä huolimatta olisi kyettävä lyhyesti esittämään keskeisimmät periaatteet, vaikkapa

• Tosi kriittiset: heti
• Kriittiset: neljässä tunnissa
• Keskimääräiset: 16 tunnissa palveluaikana
• Lievemmät: 32 tunnissa palveluaikana

Tämän lisäksi tarvitaan virkkeen–kahden mittaiset kriteerit kiireellisyysluokille. Sillä selostuksella pitää saada käyttäjä ymmärtämään, että yksittäisen käyttäjän kannalta isokaan pulma ei vaikkapa 1000 työntekijän organisaatiossa yleensä nouse prioriteettilistan kärkeen.

Useimmissa ulkoistussopimuksissa on klausuuli, että on asiakkaan vastuulla tiedottaa organisaatiossaan sopimuksen sisällöstä. Jostain merkillisestä syystä tämä jää melkein säännönmukaisesti hoitamatta; peliväsymyksestäkö, mene ja tiedä. Varsinkin silloin, kun palvelunsaaja (esimerkiksi tietohallinto) on eri taho kuin käyttäjäkunta (liiketoimintojen henkilökunta), tarpeeton arvostelu saattaa hyvinkin kohdistua neuvottelupöydän kummallekin reunalle. Näin ollen tämän asian hoitaminen asianmukaisesti on kummankin sopimusosapuolen etu.