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. http://www.tivi.fi/Kaikki_uutiset/if-otti-tiedolle-ulkoistetun-palvelun-omiin-kasiin-samalla-rahalla-enemman-6247634

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

Arvon mittaaminen service deskissä

Arvon mittaaminen on periaatteessa helppoa. Teemme joka päivä arvomittauksia kun päätämme ostaa jotain tai käyttää jotain palvelua. Yleensä päätöksemme perustuvat aikaisempiin kokemuksiin, valitsemme tuotteita ja palveluja, jotka ovat hintansa tai vaivansa arvoisia. Arvoa lisää kohteen antama hyöty ja mielihyvä. Arvoa vähentävät kohteen hinta, mahdolliset laatuongelmat, siihen liittyvä vaiva ja epävarmuus. Avoimilla markkinoilla kilpailu pitää yleensä huolen siitä, että tuotteet ja palvelut tuottavat arvoa. IT palvelu ja service desk eivät toimi avoimilla markkinoilla. Palvelun vaihtaminen on vaikeaa tai mahdotonta. Asiakkaat ovan yhden palvelutoimittajan vankeja.

IT palvelun tai service deskin toimintaa mitataan yleensä aktiviteettien perusteella eli SLA-mittareilla: palvelujen päälläoloaika, vastausaika, tikettien käsittely jne.  SLA mittarit ovat vain harvoin kytköksissä arvoon. Jos katko estää työnteon kokonaan, niin silloin katkon pituus voi olla suoraan verrannollinen menetettyyn arvoon. Valitettavasti useimmat näistä tavallisista mittareista ei mittaa todellista arvoa. Otetaan pari esimerkkiä.

Jos sähköpostipalvelin on nurin 15 minuuttia keskellä työpäivää, mitä arvoa menetetään? Toki voi laskea että kaikki 10.000 käyttäjää menettivät 15 minuuttia, ja näin saadaan kova hinta, pari miestyövuotta, mutta se on älytöntä. Ei taatusti kannata maksaa edes yhden miestyövuoden hintaa siitä että varmistetaan 100% käytettävyys. Todennäköisesti palvelukatkosta ei ole juuri mitään haittaa. 

Käyttäjällä on ongelma. Sen sijaan että service desk hakisi ratkaisun ongelmaan, tukihenkilö opettaa asiakkaalle helpomman tavan tehdä asia. Puhelu kestää puoli tuntia ja varsinaista vikaa ei ratkaista, mutta käyttäjä hyötyy neuvosta joka päivä 15 min.

On helppoa mitata katkon kesto ja on helppoa mitata puhelun kesto. Kumpikaan ei kerro juuri mitään arvosta. Lähes kaikki mittarit, joita olemme tottuneet käyttämään Service Deskeissä, mittaavat aktiviteetteja. Vastaaminen on aktiviteetti ja sen nopeus on aktiviteetin ominaisuus. Tiketin käsittely on aktiviteetti ja sen nopeus on aktiviteetin ominaisuus. Asiakkaan tyytyväisyys puhelinkeskusteluun on aktiviteetin ominaisuus. Kaikki prosessimittarit keskittyvät prosessin toiminnan mittaamiseen, mutta toimiva prosessi ei välttämättä tuota arvoa.

Oma käsitykseni on, että service deskin arvo voidaan jakaa kahteen osaan:

1) tietotekniikasta johtuvan menetetyn työajan vähentäminen

2) työn tehostaminen tai helpottaminen tietotekniikan avulla

Nämä molemmat vaikuttavat asiakkaiden saamaan arvoon. Niiden mittaaminen ei ole ihan yksinkertaista.

Service Deskin ulkoistaminen

Organisaation kannattaa ulkoistaa tehtäviä niihin erikoistuneille yrityksille, mutta on tärkeää, että ulkoistettu tehtävä ymmärretään hyvin ja tiedetään miten se liittyy omaan toimintaan. Ulkoistetun tehtävän tulee olla selkeä kokonaisuus, joka voidaan helposti erottaa organisaation muusta toiminnasta. Tietotekniikassa esimerkiksi konesalin ja palvelimien pyörittäminen on yleensä tällainen tehtävä. Palvelimet tarvitsevat sähköä, jäähdytystä, valvontaa ja turvaa. Suunnilleen samalla kustannuksella hoitaa 1000 tai 2000 palvelinta ja tämän takia harvat organisaatiot tuottavat itse omat konesalipalvelut, useimmille riittää ostettu kapasiteetti. Isompi konesali toki vaatii enemmän sähköä ja jäähdytystä, mutta suurempi keskus voi kehittää parempia menetelmiä esimerkiksi lämmön talteenottoon jne.

Service desk voidaan nähdä samanlaisena helposti ulkoistettavana palvelukokonaisuutena. Mielestäni tämä on virhe ja se johtuu siitä, että päättäjällä on virheellinen käsitys service deskin toiminnasta. Service deskin tehtävänä on olla käyttäjien kontaktipiste erilaisissa asioissa. Näitä ovat tilaukset, muutokset, ongelmat ja viat. Kaikki nämä asiat kytkeytyvät tiiviisti organisaation toimintaan. Tilausten tehokas käsittely voi edellyttää muutoksia organisaation toiminnassa. Vikojen ja ongelmien aiheuttajiin pitää puuttua. Ulkoistuskumppanin on vaikea ryhtyä kehittämään asiakkaansa toimintaa. Ulkoistaminen ei aina tuota toivottua tehokkuutta ja selkeyttä. Pahimmillaan sotkun ulkoistamisesta tulee ulkoistettu sotku.

Service desk -palvelun tuottaja tuottaa luonnollisesti palvelua monelle asiakkaalle ja palvelutuottajan intresseissä on palvelun tehostaminen ja standardointi. Asiakkaan kannalta tämä on harvoin toivottava kehitys. Palvelun hinnoittelulla ja palvelusopimuksilla on toki ohjaava vaikutus palvelun tuottajaan, mutta kokemusten mukaan ne eivät läheskään aina toimi kovin hyvin. Palvelun tuottajalla ei ole minkäänlaista mielenkiintoa turhien häiriöiden poistamiseen jos palvelusta maksetaan yhteydenottojen perusteella. Kiinteähintaisen palvelun tuottajan intresseissä on yhteydenottojen vähentäminen, mutta tämä sujuu parhaiten rajaamalla tiukasti käsiteltävät asiat ja työntämällä mahdollisimman paljon asioita asiakaan käsiteltäväksi. Huono palvelu myös vähentää yhteydenottoja tehokkaasti.

Service deskin ulkoistaminen onnistunee parhaiten silloin, kun palvelun tuottaja vastaa myös kaikista tietotekniikkapalveluista. Silloin palvelun tuottajan intresseissä on palvelun kehittäminen ja turhien häiriöiden poistaminen. Tämä toimii parhaiten silloin, kun asiakkaan liiketoiminta ei ole kovin tietotekniikakeskeistä. Silloin tietotekniikkaa käytetään standardivälineillä ja varsinaisen liiketoiminnan kehittämiseen ei liity tietotekniikan hyödyntäminen. Kokemusteni mukaan tällainen toiminta on harvinaista. Monien organisaatioiden toiminnan kehittäminen nivoutuu tiiviisti yhteen tietoteknisten ratkaisujen kehittämisen kanssa.

Valtionhallinnossa on käynnistymässä laaja ulkoistus. Valtori ryhtyy tuottamaan toimialariippumattomia it-palveluja valtion eri organisaatioille. Tämä sisältää myös Service desk -palvelut. Oma käsitykseni on, että tämä on virhe. Tuki on todellisuudessa toimialariippuvaa, joten eri yksiköiden on hoidettava oma tukensa itse, mutta lisäksi ne joutuvat maksamaan keskitetyn organisaation palveluista. Jos Valtori olisi kaupallinen palvelu, se tekisi pian konkurssin, mutta valtiollisena sillä on monopoli, joten se voi tuottaa kalliita ja huonoja palveluja.

Ongelmat

Löysin twitter-arkistosta vanhan twiittini syyskuulta 2009: It was fun to explain the concepts of incident, problem, error KE to a class who had not heard the terms before. They have power! Eli olin selittänyt insidentin, ongelman, virheen ja tunnetun virheen käsitteitä kurssilla ja saanut innostuneen vastaanoton. Nuo käsitteet selkeyttivät monia asioita ja ihmiset tajusivat havaitsemiaan ilmiöitä käsitteiden avulla. Ne auttoivat jäsentämään omaa työtä ja olivat siinä mielessä hyödyllisiä.

Jos määritelmät ovat unohtuneet, niin kertaan niitä tässä nopeasti. Itilin määritelmän mukaan ongelma (problem) on yhden tai useamman häiriön (insidentin) tuntematon perussyy (root cause) ja error tai known error on sitten tunnistettu virhe, joka aiheuttaa insidentin.

Kun itiliä kirjoitettiin, havaittiin että usein häiriöiden korjaaminen vei niin paljon aikaa, ettei niiden syihin ehditty puuttua. (Kun itse olin asiakaspalvelun päällikkö, huomasin että usein syynä ei ollut mikään kiire, vaan ennemmin laiskuus.) Tämän takia päätettiin luoda erillinen ongelmanhallinnan prosessi eli Problem Management. Prosessi osoittautua vaikeaksi ja se sai monta erilaista ja väärää tulkintaa. Ongelmanhallinnasta tuli usein vain tapa käsitellä vaikeita häiriöitä. Versio 3:n kirjoittajat kirjoittivatkin prosessin uusiksi havaitsemiensa käytäntöjen pohjalta eli kirjasivat väärinkäsitykset uudeksi parhaaksi käytännöksi. Tämä sitten korjattiin vuoden 2011 versiossa, mutta lopputulos ei onnistunut vieläkään.

Itilin ongelmanhallinta on epämääräinen käsite. Pohjimmiltaan ongelmanhallinta ja häiriönhallinta ovat samoja prosesseja ja tekevät samoja asioita. Tämä on resurssien tuhlausta ja sotkee toimintaa. On aivan selvää että yksi prosessi riittää häiriöiden ratkomiseen.

Olen aiemmin tässä kirjoitussarjassa erottanut asiakkaan ongelman ja häiriön toisistaan. Asiakkaan ongelma on tilanne, jossa asiakas tarvitsee apua jonkin tavoitteen saavuttamiseen. Häiriö on tilanne, jossa joku asia ei toimi halutulla tavalla. Häiriö voi aiheuttaa asiakkaan ongelman, mutta ongelmia voi olla ilman häiriöitä. Häiriön korjaamisen pitää ulottua myös häiriön aiheuttajien käsittelyyn. Emme missään nimessä tarvitse erillistä prosessia vaikeiden häiriöiden korjaamiseen, on vastuutonta toimintaa palauttaa vain palvelu takaisin selvittämättä miksi se häiriintyi.

On selvää, että palveluja pitää kehittää. Tunnetut viat (Known Error) ovat jokapäiväinen ilmiö. Kaikkia vikoja ei kannata korjata. Asiakkaiden ongelmia voi myös ilmetä ilman minkäänlaisia häiriöitä eli asiakas joutuu ongelmiin vaikka palvelut toimivat aivan oikein. Häiriöt voivat toistua vaikka niiden aiheuttajat on korjattu.

Itil tarjoaa liudan ”prosesseja” palvelun kehittämiseen ongelmanhallinnan lisäksi, löytyy jatkuvuuden hallinta, kapasiteetin hallinta tietoturvanhallinta ja tietysti jatkuva palvelun kehittäminen. Jos siis äkilliset tilantarpeet aiheuttavat palvelukatkoja ja tietoturvariskejä niin mikä ”prosessi” ottaa vastuun?

Ehdotan, että nämä kaikki korvataan yhdellä prosessilla. Riskienhallinta on tarpeellinen, suorastaan välttämätön toiminta, joka tunnistaa riskit ja valitsee niiden käsittelytavan. Lisäksi kaikilla organisaatioyksiköillä ja jopa henkilöillä pitää olla vastuu palvelun kehittämisestä. Jokaisen pitää tarttua havaitsemiinsa mahdollisuuksiin parantaa palvelua.

Mielestäni siis ongelmanhallintaa ei tarvita. Se voidaan korvata riskienhallinnalla. Service Deskin vetäjällä ja kaikilla prosessipäälliköillä on vastuu olla aktiivisesti mukana palvelun laadun kehittämisessä.

Häiriöistä palveluun

Tämä on toinen osa asiakastuen uudistamista käsittelevässä artikkelisarjassa.

Asiakastuen ympäristö on muuttunut valtavasti viimeisten vuosikymmenten aikana. Muinaiset suurtietokoneet ovat kutistuneet ja sujahtaneet ihmisten taskuun. Peruskäyttäjien osaamistaso on noussut merkittävästi. On selvää että sekä asiakastuen, että sen prosessien pitää uusiutua.

Asiakastuen käyttämä häiriöhallinta, incident management on ensimmäinen prosessi, jonka itilin soveltaja ottaa käyttöön ja usein myös ainoa prosessi, joka saadaan toimimaan kunnolla. Prosessin tukena on käytetty tikeitöintijärjestelmiä, joista ensimmäiset otettiin käyttöön 1980-luvulla. Niiden perusperiaatteissa ole juurikaan tapahtunut muutoksia, tiketit avataan, luokitellaan, käsitellään ja suljetaan.

Häiriönhallinnan ensisijaisena tavoitteena on palauttaa palvelu ennalleen. Tämä juontaa juurensa historiasta, jossa palvelut olivat epäluotettavia ja hyvin häiriöalttiita. Nykyaikaisen asiakastuen tehtävänä on tuottaa arvoa auttamalla asiakkaita, joten häiriöiden hoitaminen ja palvelun palauttaminen ei riitä.

Nykyaikainen asiakastuki ei sotke asiakkaan pulmaa ja teknistä häiriöitä toisiinsa, koska ne ovat eri asioita. Palvelun palauttaminen ei ole sama asia kuin asiakkaan ongelman ratkaisu. Asiakastuki keskittyy ensisijaisesti ratkaisemaan asiakkaiden ongelmia. Tarvittaessa se voi myös ratkoa teknisiä häiriöitä, mutta nämä ovat kaksi eri prosessia. Tässä hyvin yksinkertainen esimerkki:

Tärkeä järjestelmä kaatuu kriittisenä hetkenä. Asiakaspalvelun henkilöillä on kaksi vaihtoehtoa, joko he ryhtyvät korjaamaan järjestelmää ja palauttamaan palvelua ennalleen, tai he jättävät järjestelmän korjaamisen seuraavaan aamuun ja keskittyvät häiriön kohteeksi joutuneiden asiakkaiden auttamiseen. Kumpi vaihtoehto on oikea?

Kuvittele että olet illalla kaupan kassalla jonottamassa, kun jonottamasi kassan järjestelmä kaatuu. Varmasti arvostat toimenpiteitä, joiden ansiosta pääset maksamaan ostoksesi mahdollisimman nopeasti. Epäkunnossa olevan kassakoneen ehtii kyllä korjata seuraavana aamuna.   

Asiakkaan ongelma on tilanne, jossa asiakas tarvitsee apua jonkin tavoitteen saavuttamiseen. Yleensä esteenä on jokin tietotekninen järjestelmä, joka ei tunnu toimivan halutulla tavalla. Taustalla voi olla jokin häiriö, mutta usein pulma johtuu siitä, että asiakas ei ole osannut käyttää järjestelmää tai että asiakkaalla on virheellinen käsitys järjestelmän toiminnoista. Asiakastuen tehtävänä on ratkaista asiakkaan ongelma. Hyvä tulos voidaan saavuttaa monella tavalla. Asiakkaalle voidaan vaikka neuvoa parempi tapa saavuttaa haluttu tavoite. Asiakkaan ongelma ei välttämättä liity mihinkään infrastruktuurin komponenttiin.

Häiriö on tilanne, jossa jokin järjestelmä ei toimi halutulla tavalla. Häiriö ei välttämättä liity mihinkään asiakkaaseen tai palveluun, mutta se voi haitata useita asiakkaita ja palveluja. Häiriö sen sijaan liittyy johonkin tiettyyn infrastruktuurin komponenttiin. Sama häiriö voi vaikuttaa asiakkaisiin hyvin eri tavoin. Yksi asiakas ei ehkä huomaa sitä ja toinen joutuu suoranaisiin vaikeuksiin sen takia. Kehittynyt palveluntuottaja valvoo palvelujaan ja kykenee havaitsemaan ja korjaamaan useimmat häiriöt ennen kuin ne näkyvät asiakkaille. Häiriöiden korjaamisessa nopeus on tärkeää

Asiakkaiden ongelmien käsittely häiriöinä ohjaa toimintaa väärään suuntaan. Asiakkaan neuvominen vie enemmän aikaa kuin yksinkertaisen ratkaisun antaminen. Uuden toimintatavan opettamisesta voi kuitenkin olla paljon hyötyä.

Lisäksi asiakastuki vastaanottaa tilauksia ja palautetta asiakkailta. Hyvin toimivalla asiakastuella on siis toimiva menettely häiriöiden, ongelmien, palautteen ja tilausten käsittelyyn.

Tämä ei ole mikään suuri muutos, mutta se tuntuu olevan monille silti vaikea ymmärtää, jos oma ajattelu on tiukasti kiinni itilissä. Kannattaa kuitenkin yrittää, koska uudesta mallista on paljon hyötyä. Kirjaaminen muuttuu helpommaksi, koska asiakkaan ongelmia ei tarvitse kytkeä konfiguraatiotietoihin. Niiden priorisointikin voi olla turhaa, edellyttäen että ne pystytään ratkaisemaan nopeasti. Asiakkaan ongelmien lukumäärä, luonne ja kesto ovat hyödyllistä tietoa palvelun kehittämiselle.

Häiriöt ovat vikoja, joiden korjaamisessa tarvitaan täsmällistä tietoa ja jotka on syytä priorisoida. Häiriöitä on normaalisti vähemmän kuin asiakkaiden ongelmia, joten häiriökirjauksia tarvitaan vähemmän.

Seuraavassa artikkelissa pohdin häiriöiden aiheuttajien käsittelyä.

On aika uudistaa asiakastuki

Viimeistelin esitystäni USA:n itSMF:n FUSION konferenssiin, joka on parin viikon päästä Washington DC:ssä. Huomasin samalla, että en ole kirjoittanut asiakastuen uusimisesta juurikaan suomeksi. Siksi ajattelin kirjoittaa muutaman artikkelin aiheesta. Tämä on ensimmäinen sarjassa.

WP_20141005_003

Ihmisten vaatimustaso kasvaa ja toimintamallit muuttuvat. Vanhat palvelumallit eivät aina toimi muuttuneessa ympäristössä. Toivoisin että Helsingin Silakkamarkkinat pysyisivät hengissä, mutta pahalta näyttää. Kalastajaveneiden määrä hiipuu. Ihmiset eivät enää osta talven suolasilakoita kerralla. Silakkamarkkinoiden alkuperäinen syy ja tarkoitus ovat jo kadonneet.

Service desk -toimintamalli on paljon nuorempi kuin 1700-luvulta peräisin olevat Silakkamarkkinat, mutta senkin ympäristö muuttuu. Pilvipalvelut, tabletit, älypuhelimet ovat muuttaneet vuonna 1989 kuvatun Service Desk -mallin ympäristön.

Asiakastuen toimintamalli on tai oli alkujaan häiriökeskeinen puhelinpalvelu. Käyttäjä soittaa kun jokin ei toimi. Asiakastuki sitten ratkaisee ongelman tai välittää sen edelleen. Häiriö kirjataan, luokitellaan, käsitellään ja suljetaan kun häiriö on hoidettu ja palvelu on palautettu ennalleen.

Standardointi on ollut keskeinen elementti häiriökeskeisessä toimintatavassa. Häiriöt on helppo korjata kun kaikki käyttävät standardoituja työkaluja. Kaikki laitteet löytyvät laiterekisteristä ja laitteiden viat kirjataan sinne. Asiakastuella on korjausohjeet ja varaosat tavallisimpien häiriöiden varalta. Toimintaa mitataan ja arvioidaan häiriöiden käsittelyn perusteella.

Uuden asiakastuen maailmassa ei ole standardeja, ei ole välttämättä laiterekisterejä, eikä toiminta keskity häiriöihin. Laitteet kehittyvät ja vaihtuvat liian nopeasti. Palvelut ovat pilvessä. Perustekniikka on paljon vakaampaa kuin 1990-luvulla. Asiakkaat ovat entistä taitavampia hallitsemaan omia laitteitaan ja selvittämään yksinkertaiset ongelmat. Asiakastukea tarvitaan sitten kun omat taidot eivät enää riitä. Jos asiakastuen osaaminen ei riitä, apu haetaan muualta. Sosiaalinen media ja erilaiset verkosta löytyvät lähteet tarjoavat usein ratkaisun hankaliinkin pulmiin.

Perinteisiin juuttunut asiakastuki ei välttämättä huomaa muutosta itse. Jos asiakkaat näkevät että asiakastuesta ei ole apua, he eivät ota yhteyttä. Vielä löytyy niitä asiakkaita, jotka toimivat perinteisen mallin mukaan ja asiakastuki voi huomaamattaan keskittyä palvelemaan vähemmistöä.

Uuden asiakastuen pitää keskittyä asiakkaisiin ja heidän auttamiseen. Auttaminen ei ole välttämättä sama asia kuin asiakkaan ongelman tekninen ratkaiseminen. Asiakkaalle voidaan myös tarjota uusi tapa tehdä asioita tai vaikka kokonaan uusi työkalu.

Häiriötikettien käsittelyn mittaaminen on vanhentunut tapa arvioida asiakastuen toimintaa. Hyvän ratkaisun tarjoaminen sosiaalisessa mediassa voi poistaa satoja ”häiriöitä”, mutta luotu arvo ei näy millään häiriökeskeisellä mittarilla mitattuna.

Uusi asiakastuki ei istu luurit päässä odottamassa puheluja. Sen sijaan asiakastuki on aktiivinen, opiskelee uusia ratkaisuja, esittelee vaihtoehtoja, näkyy sosiaalisessa mediassa ja keskittyy asiakkaaseen.

Tärkeä elementti uudessa asiakastuessa on erilaisten palvelukanavien avaaminen. Palveluportaali on tärkeä elementti. Sieltä asiakkaat löytävät tiedotteet, voivat tilata asioita ja olla yhteydessä asiakastukeen muutenkin kuin puhelimella. Sosiaalinen media on hyvä kanava ja siellä pitää olla aktiivisesti mukana. Kannattaa myös avata fyysinen palvelupiste, jos se vain on mahdollista, koska asiakkaat ja heidän tietotekniikkansa ovat mobiileja. Asiakkaan on helppoa tulla palvelupisteeseen näyttämään ongelma. Palvelupiste on myös hyvä paikka auttaa asiakas alkuun esimerkiksi uuden laitteen kanssa.

Tässä luettelo toimenpiteistä:

  • Siirry arvopohjaiseen mittaamiseen, lopeta aktiviteettien mittaaminen. Arvon mittaaminen on vaikeampaa, mutta aktiviteettien mittaaminen voi ohjata toimintaa väärään suuntaan.
  • Ota sosiaalinen media käyttöön.
  • Perusta palvelupiste tai -pisteitä. Etsi niille sopivat aukioloajat ja toimintatavat. Sijoita piste paikkaan, jonne asiakkaiden on helppo tulla.
  • Uusi kirjausjärjestelmä sellaiseksi, että pystyt helposti erottelemaan erilaiset asiat. Varo itilin kangistamia järjestelmätoimittajia.
  • Kuuntele asiakkaita ja kysy heidän toiveitaan. Ole aktiivinen ja mieti ennakkoluulottomasti miten tietotekniikka voisi auttaa heitä heidän työssään.

Tämä on ensimmäinen osa artikkelisarjasta, joka käsittelee asiakastuen uudistamista. Kommentit ovat tervetulleita.

 

%d bloggers like this: