Raportointi ja Dashboardit

Keskustellessamme organisaatioiden kanssa, törmäämme pääosin kahteen haasteeseen raportoinnissa:

1. Toisilla tämä puuttuu täysin,
2. Toisilla se on vahvasti siiloutunut.

On minulla tosin tullut vastaan myös kerran yritys, jolla ei ollut ongelmia laisinkaan.

Keissi 1.: Ei ongelmia

Olimme juttelemassa pk-seudun välittömässä läheisyydessä ex-kollegan kanssa erään julkisen terveydenhuoltosektorin organisaation edustajan kanssa.

Keskustelu oli avointa ja verkkaisaa, keskustelimme mitä puhelinjärjestelmiin nyt kuuluikin. Kun pääsimme pureutumaan raportointiin, kysyin toisella puolen pöytää istuvalta henkilöltä, millaisia tarpeita heillä on sen suhteen? Vastaus oli hyvin yksioikoinen - ongelmia ei ollut.

Pyysin herraa hieman avaamaan ajatusta, miten niin ei ollut? Hän ilmoitti että heillä vastataan kaikkiin puheluihin.

Logiikka oli niin pettämätön, ettemme keksineet enää tuossa sananpartta sanottavaksi.

Heille, jotka eivät tiedä puhelinjärjestelmien raportoinnista, niin voin mainita että pelkästään soivat puhelut ovat aina vain jäävuoren huippu. Taustalta löytyy tyypillisesti suuri määrä vastaamattomia, eli luopuneita, ja muita palvelua tavoittelleita ihmisiä. Myös aukioloaikojen ulkopuoliset kontaktit on syytä rekisteröidä edes jollain tasolla.

Tässä tapauksessa emme päässeet kauppoihin asti mutta kokemuksena tämä oli ainutlaatuinen.

Keissi 2.: Sitä saa mitä mittaa

Erilaisia kommervenkkejä on nähty maailman sivu terveydenhuoltosektorilla toisissakin merkeissä. Näitä ovat olleet esimerkiksi THL:n raportointivaatimukset 'välittömään hoidontarpeen arviointiin' liittyen (toivottavasti muistan termit oikein).

Sitä saa siis, mitä mittaa - tai jättää mittaamatta.

Raporttien avulla voidaan kehittää liiketoimintaa

Data on uusi öljy, sanotaan. Raportointi on taasen yksi tapa käsitellä dataa ja luoda siitä liiketoiminnan käyttöön oleellista tietoa.

Olen itse ollut munklaamassa mitä erilaisempia raportteja, mitä erilaisemmista lähteistä niiden kohteisiin (mm. BI-ratkaisut). Puhelinjärjestelmissä usein puhtuaan CDR- tai CIL-datasta (puheluiden raakadataa).

Erinäisiä temppuja tekemällä datasta saadaan irti todella hyödyllistä, ja joissakin tapauksissa raportoinnin kytkentä liiketoimintaan on hieman sama kuin laittaisi autoon ajovalot päälle. Ei kukaan pakota ajamaan sokkona. Raportoinnin tulisi silti olla tavoitteellista, sekä aidosti organisaation toimintaa tukevaa.

Järjestelmien moninaisuus on eittämättä jotain sellaista, mikä jää monilta huomioimatta. Tällä tarkoitan sitä, että käytännössä jokainen järjestelmä yleisesti ottaen tulkitsee hieman omalla tavallaan hyvinkin samankaltaisia tilanteita.

Tämä tulee ottaa huomioon, kun olette joko päivittämässä olemassa olevaa ympäristöä tai haluatte tehdä jollain tasolla fiksua raportointia monikanavaisesti.

Vanhan järjestelmän datan siirtäminen uuteen ei ole temppu tai mikään, kun kyseessä on asetuksiin liittyvät asiat - nämä kun saa hakattua sisään vaikka manuaalisesti. Haasteet tulevat yleensä esille kun pitäisi siirtää raportointia uuteen ympäristöön. Monesti tekemätön paikka, ja raportit vanhasta ratkaisusta kannattaakin ottaa siirtymän päätteeksi.

Monikanavaisessa raportoinnissa on monesti samat haasteet kuin asetuksienkin kanssa. Tavara on hujanhajan, eikä se ole vertailukelpoista keskenään. Toinen järjestelmä saattaa tulkita vaikkapa jonotusajan tyystin toisella tavoin kuin toinen.

Dashboardit eli tuttavallisemmin konepellit

Siinä missä raportointi keskittyy kehdosta hautaan dataan, dashboardeilla saadaan näyttävää reaaliaikaista tietoa käyttäjille nykyhetkestä.

Jo vuosikymmen sitten olin mukana kehittelemässä varmasti erästä yhtä ensimmäisistä webbiappeista pohjoismaissa, jossa varauspalvelun verkkosivulle välitettiin reaaliaikaista tietoa asiakaspalvelun puhelujonotilanteesta.

Keissi oli sinällään yksinkertainen. Napattiin vain asiakaspalveluympäristön reaaliaika-rajapinnalta tietoa, munklattiin oikeaan esitettävään muotoon ja siirrettiin verkkosaitille näkyville.

Olihan se huikea fiilis, kun asiakkaan ei tarvinnut edes soittaa asiakaspalveluun.

Tämän jälkeen kehitimmekin muutaman muunkin tuotteen, mm. verkkosivuille integroidun soittopyynnön (aito soittopyyntö, joka meni oikeasti jonoon - ei sähköpostien syövereihin).

Nykypäivänä moiset vimpaimet on arkisia, mutta 2010-luvun taitteessa, se oli jotain tosi makeeta.

Aikaisemmin jo tässäkin sarjassa mainitsin sähköiskuista asiakaspalvelijoiden tuoleihin vastaus %:n nostamiseksi. Tämä ei koskaan mennyt läpi, vaan kehitimme kyseiselle yritykselle kustomoidun reaaliaikanäytön, jota peilattiin kaikkien toimipisteiden näytöillä - myös niin että kivijalkakaupassa käyvät asiakkaatkin näkivät tiedon.

Kyllähän tuolla oli iso merkitys asiakaspalvelun kehittämisen kannalta. Jonkinlainen psykologinen ajatus siitä varmaan tuli asiakaspalvelijoille - mikäli jonot täynnä, niin kaveria ei jätetä?

Paljon on menty näistä ajoista eteenpäin.

Nykyaikana modernien sekä aidosti edistyksellisten asiakaspalveluympäristöjen mukana sisäänrakennettuna tulee reaaliaikaiset selainpohjaiset näkymät, raportointi on monikanavaista ja rajapinnat mahdollistavat huikeitakin suorituksia.

Protip:

• Sopikaa järjestelmän vaihdon ajankohta sellaiseen hetkeen, mikä vähiten rassaa raportteja (esim. kuunvaihde).
• Uutta ratkaisua hankkiessa, kiinnittäkää huomiota datan siirtämiseksi uuteen (mikäli mahdollista) sekä monikanavaiseen raportointiin.
• Pyydä toimittajalta tietoa reaaliaikaista näkymistä ja kiinnittäkää huomiota myös integraatiomahdollisuuksiin, mm. BI-järjestelmiin.