Kuinka helpottaa palvelusetelillä tehtävää ajanvarausta Helsingin kaupungin hammashoitoon?
Tämä case kuvaa sitä, miten lähdin ratkaisemaan kohtaamaani oikean elämän ongelmaa / kehityshaastetta ohjatusti Osaangon yhteistyössä Ciscon ja Laurea ammattikorkeakoulun kanssa toteuttamalla Futudemy-kurssilla.
Blogissa kuvaan mahdollisen ratkaisun näihin ongelmiin, ja toivon että siitä olisi hyötyä niin terveydenhuollon palveluja ja ratkaisuja kehittäville kuin muille, jotka kaipaavat lisää osaamista tai ideointiapua palveluiden automatisointiin ja asiakaskokemuksen parantamiseen. Tämä on hyvä esimerkki siitä, että miten oikean elämän ongelmia voidaan lähteä ratkaisemaan käyttäjälähtöisesti.
Tässä alla lyhyt kuvaus kohtaamastani ongelmasta.
Kuva 1: Kuvaus kohtaamastani ongelmasta
Kurssin tavoitteena oli oppia, että mitä ohjelmointirajapinnat eli APIt ovat ja miten niitä pystyy hyödyntämään eri alojen ja asiakkaiden tarpeiden ratkaisemisessa uudella tavalla yhdistämällä dataa ja teknologiaa. APIt mahdollistavat myös uusien innovatiivisten liiketoimintamallien luomisen. Olemassa olevia rajapintoja hyödyntämällä pystyy lyhentämään kehityksen käytettävää aikaa, vähentämään kehittämistyön kustannuksia ja hyödyntämään valmiita toiminnallisuuksia niiden alusta alkaen rakentamisen sijaan. Tätä opeteltiin oikean kehityshaasteen parissa käytännössä, käymällä läpi API-teoriaa ja niihin liittyviä käytännön esimerkkejä.
Jos APIt eivät ole aiemmin tuttuja, niin tässä lyhyt kurssilla esitetty määritelmä:
”API tai sovellusohjelmointirajapinta on ohjelmiston välittäjä, jonka avulla eri sovellukset voivat keskustella toistensa kanssa; jakaa tietoa, toimintoja ja resursseja muiden kanssa.”
Kurssi oli jaettu neljään kahden tunnin ohjattuun tapaamiseen, joiden aikana tapahtunutta työskentelyä ja kehityshaasteen ratkaisua kuvaan lyhyesti seuraavaksi. Lopuksi kerron omat oppini kurssista. Tämä case jakaantuu seuraaviin osioihin:
Intro
Vaihe 1 - Ideointi
Vaihe 2 - Palvelupolku
Vaihe 3 – Toiminnot, hyödyt ja haasteet
Vaihe 4 - Pitchin rakentaminen & lopullinen tuotos – Palvelupolun prototyyppi
Mitä itse opin kurssin aikana
Vaihe 1 - Ideointi
Ensimmäisessä vaiheessa jokaisen tuli valita ongelma, mitä lähtee ratkaisemaan. Minulla oli aiemmin keväällä ollut huono kokemus palvelusetelin kautta tehtävän hammashoidon varaamisesta ja hoidon toteuttamisesta, joten valitsin sen. Tämä oli siinäkin mielessä hyvä ratkaisu, koska minulla oli näin käyttäjätutkimus tehty valmiiksi ja olin kirjoittanut palautteen kohtaamistani palvelupolun puutteista hoidon toteuttaneen yksityisen yrityksen palautekanavaan.
Ensimmäisessä vaiheessa hyödynnettiin menetelmää, jonka avulla luodaan uusia ajatusmalleja ongelman ympärille ja ideoidaan ratkaisuvaihtoehtoja. Itse pystyin kirjaamaan tähän kohtaamiani haasteita palvelupolulla aiemmasta kokemuksesta. Tässä ensimmäisessä menetelmän vaiheessa myös toinen osallistuja oli mukana ideoimassa, mutta hän päätyi lopulta keskittymään itse kohtaamaansa ongelmaan, eli miten palvelusetelien ostolaskujen liitteet liikkuvat, tai eivät liiku, hoitoalalla. Kuva 2 alla kuvaa tätä vaihetta ja meidän tuotoksiamme.
Kuva 2: Ensimmäisen ideointivaiheen työstöä
Kirjasimme seuraavia ajatuksia nykytilanteeseen liittyen:
Asiakas haluaa varata ajan soittamalla asiakaspalveluun
Asiakaspalvelun työntekijät eivät tiedä, että kauan eri toimenpiteisiin menee aikaa
Palvelusetelien käyttö voidaan tehdä vain tietyille palveluntarjoajille
Asiakaspalvelun työntekijä eivät näe palvelusetelin toimenpiteitä
Vain osa hammaslääkäreistä tekee palvelusetelin toimenpiteitä
Asiakas ei näe kenellä on vapaata (tai kuka haluaa ottaa palvelusetelillä lisää asiakkaita)
Asiakas hommaa palvelusetelin soittamalla? / lähetteellä?
Asiakkaan ei tarvitse käyttää rahaa
Ainoastaan harvoissa paikoissa on vapaita aikoja palvelusetelin toimenpiteitä
Asiakas joutuu itse hommaamaan palvelusetelin
Palveluseteli lähetetään jostain sinne missä palveluseteli tarvitaan
Palvelusetelin saa sähköisesti
Palveluseteli lähetetään käsittelyn jälkeen jonnekin, missä ostolaskut käsitellään?
Varattua aikaa ei voi muuttaa kuin vain asiakaspalveluun soittamalla
Seuraavissa vaiheissa (Kuva 3) kyseenalaistetaan näitä oletuksia ja ideoidaan uusia ratkaisuja.
Kuva 3: : Ideointivaiheen oletusten kyseenalaistamista ja uusien ratkaisujen ideointia
Entä, jos kyseenalaistamme nykytilanteen?:
Asiakas ei halua soittaa
Asiakas haluaa listan ajoista, jotka voi varata palvelusetelillä ja sopivat hänen kalenteriinsa
Asiakas haluaa varata ajan itsenäisesti
Palveluntarjoajat voisivat markkinoida palvelusetelillä tarjottavia palveluita
Palvelusetelit voidaan tehdä mille vain palvelutarjoajalle
Asiakas pystyy valitsemaan itse palveluntarjoajan eikä vain valitulta listalta
Aspan työntekijä näkevät palvelusetelien sisällön ja tietävät kauan eri toimenpiteisiin menee aikaa
Asiakas pystyy muuttamaan varatun ajan itsenäisesti
Asiakkaan ei tarvitse itse hoitaa palveluseteliä, tai mitään siihen liittyvää
Ajatteluprosessin ja hyödynnetyn menetelmän tuloksena päädyimme tällaisiin alustaviin ratkaisuihin:
Itsepalveluportaali, mistä pystyy hallinnoimaan varauksia
Alusta, mistä pystyy valitsemaan itsenäisesti haluamansa toimenpiteet ja tieto niiden kestosta
Asiakas pystyy hoitamaan kaiken asiointinsa yhden kanavan kautta
Asiakkaalle ilmoitetaan/soitetaan asiakasta lähimmästä pisteestä aikaehdotuksia
Palveluseteli liikkuu automaattisesti eri lähettelyltä kaikkien osapuolten välillä
Aikatauluehdotelmat tulee sähköisesti asiakkaalle kännykkään tms.
”Palvelusetelillä”, tai ajanvarausportaalissa on automaattisesti tieto, kuinka pitkä aika tarvitaan
Vaihe 2 - Palvelupolku
Kurssin toisessa vaiheessa lähdimme itsenäisesti hahmottelemaan palvelupolkua valittuun kehityshaasteeseen liittyen. Tässä vaiheessa oli todella paljon hyötyä siitä, kun että olin ihan vasta äskettäin itse kokenut, että miten se menee tällä hetkellä. Eli oli vähän niin kuin käyttäjätutkimus tehty valmiiksi. Alla oleva kuva (Kuva 4) esittää tuotokseni.
Kuva 4: Palvelupolku
Se menee näin:
Asiakas tarvitsee hampaiden määräaikaistarkastuksen ja on yhteydessä Helsingin kaupungin suunterveyden yksikköön
Mikäli 2 vuotta täytyy, virkailija ehdottaa palveluseteliä
Asiakas saa palvelusetelin tekstiviestillä / haluamansa kanavan kautta, mistä löytyy linkki järjestelmään / alustalle
Asiakas kirjautuu järjestelmään / alustalle
Järjestelmä ehdottaa automaattisesti palvelusetelin sisällön perusteella asiakasta lähimpänä olevien toimijoiden sopivia vapaita aikoja, jolloin kaikki tarvittavat toimenpiteet pystytään suorittamaan
Asiakas valitsee itselleen parhaiten sopivan ajankohdan, lisää sen kalenteriinsa yhdellä klikkauksella ja saa tiedon myös tekstiviestitse ajanvarauksesta. Viestissä on linkki, minkä kautta pystyy itse tarvittaessa muuttamaan varattua aikaa.
Samalla kun kuuntelin muiden esityksiä, kirjasin ylös ajatuksia, joita ottaa huomioon työskentelyn seuraavassa vaiheessa. Näitä olivat:
Voisiko asiakaspolun vaiheet 1 & 2 automatisoida? Ilmoitus 2 v täyttymisestä ja ehdotus palvelusetelistä?
Tarvitaanko vaiheessa 2 vahvaa tunnistautumista vai kirjautuuko käyttäjä automaattisesti?
Tarvitaanko käyttöliittymää hammaslääkäriä varaavalle potilaalle ja jos niin millä teknologialla? (tässä vaiheessa sekä minä ja moni muu opiskelijoista oli vielä hyvin ”äppi” eli applikaatio-orientoitunut eikä vielä ajateltu ”API-mahdollisuuksia”, eli sitä että asiat voisivat vain tapahtua automaattisesti vaikkapa automatisoidulla sähköpostilla, tekstiviestillä tai puhelinsoitolla, joiden taustalla olisi vaikkapa aikataulutusalgoritmilla). Eli mietin aika paljon käyttöliittymää, jossa käyttäjä syöttäisi tai näkisi tietoja ja sitä, millä laitteilla sen pitäisi toimia.
Tarvitaanko vaiheessa 4 vahvaa tunnistautumista vai kirjautuuko automaattisesti?
Vaihe 3 – Toiminnot, hyödyt ja haasteet
Kolmannessa vaiheessa lähdettiin miettimään tarvittavia toimintoja (Kuva 5), joilla valitun kehityshaasteen pystyisi ratkaisemaan. Mietittiin myös, että mitä hyötyjä (Kuva 6) käyttäjä voisi saada. Menetelmänä käytettiin mm. avointa APIOps Cycles -menetelmää, jota Osaango kehittää ja tukee kansainvälisesti. Menetelmällä pyritään mm. muuntamaan asiakkaan / loppukäyttäjän tarpeet ohjelmistokehittäjiä hyödyntäviksi API-tuoteominaisuuksiksi. Seuraavassa esitetään osia yhdestä menetelmään liittyvästä canvaksesta ja sen käytöstä idean kehittämiseksi.
Kuva 5: Tarvittavat toiminnot
Mielestäni luotavan ratkaisun toiminnot olisivat:
Varatun ajan lisääminen omaan kalenteriin
Asiakkaan ja toimipisteiden sijainnin löytäminen – lähimmät toimipisteet
Kalenterin synkkaus eri toimijoiden kalentereista yhteen paikkaan
Tekstiviestillä tiedot varatusta tapaamisesta
Robotille annetaan tehtäväksi automatisoida määräaikaistarkastuksista ilmoittaminen 2 v kuluttua edellisestä
Vahva tunnistautuminen
Chatbotin kautta varaukset
Halutun sijainnin määrittely, josta etsiä sopivia toimenpiteitä
Asiakas tarvitsee hampaiden määräaikaistarkastuksen, on yhteydessä Helsingin kaupungin suunterveyden yksikköön
Mikäli 2 vuotta täytyy, virkailija ehdottaa palveluseteliä
Asiakas saa palvelusetelin tekstiviestillä / haluamansa kanavan kautta, mistä löytyy tieto ja linkki järjestelmään / alustalle
Asiakas kirjautuu järjestelmään / alustalle
Asiakas valitsee itselleen parhaiten sopivan ajankohdan, lisää sen kalenteriinsa yhdellä klikkauksella ja saa tiedot myös tekstiviestillä/sähköpostilla. Viestissä on linkki, minkä kautta pystyy itse tarvittaessa muuttamaan varattua aikaa.
Järjestelmä ehdottaa automaattisesti palvelusetelin sisällön perusteella asiakasta lähimpänä olevien toimijoiden sopivia vapaita aikoja, jolloin kaikki tarvittavat toimenpiteet pystytään suorittamaan.
Kuva 6: Gains / Hyödyt
Mielestäni luotavan ratkaisun hyödyt olisivat:
Kalenteri, missä näkyy vapaat ajat valituille toimenpiteille
Lista / kartta lähimmistä yrityksistä, joista valita mieleinen
Yksi paikka mistä varata itselle sopivat ajankohdat
Varaukset voi tehdä itsenäisesti, milloin vain haluaa
Saapumisohjeet valittuun toimipisteeseen
Voisiko nämä kaksi vaihetta automatisoida? Ilmoitus 2 v täyttymisestä ja ehdotus palvelusetelistä?
Tarvitaanko vahvaa tunnistautumista vai kirjautuuko automaattisesti?
Ajanvaraukset pitää pystyä tekemään myös kännykällä, koska kaikilla ei ole tietokonetta käytettävissä
Vaihe 4 - Pitchin rakentaminen & lopullinen tuotos – Palvelupolun prototyyppi
Neljännessä vaiheessa jokainen esitteli tuotoksensa pitchaamalla sen 5 minuutin mittaisella esityksellä. Valitsin itse välineeksi Powerpointin ja pitchin rakensin NABC-menetelmän (Need-Approach-Benefit-Competition) mukaisesti. Palvelunpolun prototyypin loin ”Markin” (Kuva 7) näkökulmasta Canvassa Storyboardin muodossa ja monta siinä vaadittavaa toimintoa pystyy toteuttamaan olemassa olevien APIen avulla.
Kuva 8: Asiakaspersoona Mark
Futudemya luotsaava Osaangon tiimi Marjukka Niiniojan vetämänä teki pitchistäni / ratkaisuehdotuksestani tämän alla olevan videon, jota on sen jälkeen hyödynnetty luvallani kurssin materiaaleissa.
Linkki videoon: https://www.youtube.com/watch?v=B-ZvP4itsKU
Ratkaisun hyödyt verrattuna nykytilanteeseen ovat:
Yksi paikka, mistä saa helposti varattua itselleen parhaiten sopivan ajan palvelusetelin hoitotoimenpiteisiin silloin kuin itselleen parhaiten sopii
Palveluntuottajien palveluseteliasiakkaita palvelevien henkilöiden kalentereista noudetaan automaattisesti vapaat ajat ja näytetään lähimmät vaihtoehdot kartalla
Ei tarvitse olla erikseen yhteydessä useampaan palveluntoimittajaan heidän prosessiensa mukaisesti
Chatbot auttaa varauksen tekemisessä 24/7
Tiedot toimenpiteiden kestosta jo varausta tehdessä
Asiakkaan ei tarvitse itse muistaa palvelusetelin sisältöä, se tulee automaattisesti
Varauksen pystyy halutessaan lisäämään helposti omaan kalenteriinsa
Varausta pystyy tarvittaessa muokkaamaan helposti itse
Mitä itse opin kurssin aikana
Rajapintoja on todella paljon erilaisia. API-maailma on vähän niin kuin ”karkkikauppa” erilaisista toiminnoista, mistä voi valita haluamansa eikä tarvitse itse koodata alusta lähtien.
Kaikkea ei tarvitse koodata ja tehdä itse, vaan voi säästää paljon aikaa ja resursseja, kun hyödyntää rajapintoja. Aika moneen toimintoon löytyy jo valmis API, esimerkiksi kalenterivaraukseen, reittiohjeisiin ja viestien lähettämiseen eri kanavissa.
APIen avulla pystyy luomaan uudenlaisia innovatiivisia liiketoimintamalleja yhdistämällä dataa ja teknologiaa.
Merkittävin onnistumistekijä APIen hyödyntämisessä on ymmärtää loppukäyttäjää, mikä on heidän aito ongelmansa ja miten tuotteella tai palvelulla voidaan ratkaista se sekä tuottaa lisäarvoa loppukäyttäjälle. Ihan muotoiluajattelun perusteita kyllä, mutta pätee myös digitaaliseen palvelunkehittämiseen.
Jos aloittaa kehittämisen teknologia/työkalu edellä, se rajoittaa luovaa ajattelua. Silloin tulee helposti mietittyä kaikkia niitä rajoitteita, joita valitussa teknologiassa/työkalussa on, eikä silloin pystytä luomaan parasta mahdollista kontekstiin sopivaa ratkaisua.
Jos haluat oppia luomaan uusia dataan ja ohjelmointirajapintoihin (API) perustuvia palvelukonsepteja sekä hyödyntämään rajapintoja, vaikka et olisikaan taustaltasi tekninen, niin voin suositella tätä kurssia. Linkin takaa löydät lisätietoja kurssista ja seuraavien toteutuksien ajankohdat: https://www.futudemy.com/