Service Blueprint er en metode for å utforske brukerreisen til en tjeneste eller et produkt, hvor man, i i tillegg til å se på brukerreisen fra sluttbrukerens perspektiv, også inkluderer prosessene rundt. Dette kan for eksempel være brukerreisen sett fra perspektivet til selskapet som leverer produktet eller tjenesten, programvare, nødvendige underleverandører eller støtteprosesser. 

Ved å utforske brukerreisen på denne måten, får man en helhetlig oversikt over alle de ulike prosessene som spiller inn i én enkelt brukerreise. Da kan man enklere identifisere hvilke deler som ikke fungerer helt slik man ønsker – og hvordan man kan forbedre dem. 

Et Service Blueprint-skjema deles inn i rader, kategorisert etter de ulike aspektene av brukerresien. Disse kan være: 

• Fysiske berøringspunker på produktet eller tjenesten
• Brukerens handlinger 
• Kontaktpunkter mot brukeren 
• Usynlige kontaktpunkter mot brukeren
• Støttefunksjoner

Det kan også være andre kategorier, avhengig av typen produkt eller tjeneste og hvilke deler av brukerreisen man skal se på. Etter hvert som man kartlegger handlingene i disse radene, fører man dem inn i skjemaet og kobler dem sammen.

La oss si, for eksemplets skyld, at vi skal lage et Service Blueprint på alarm mot B2B-markedet; da kan man både se på på kjøp, installering og å komme i gang med alarmen. 

Berøringspunkter‍

Her fører man hvilke berøringspunkter man har på på tjenesten eller produktet. Om man undersøker kjøp, ser man for eksempel på: Hvor finner kunden alarmselskapet? Har de en app eller en nettside? Eller er det et bygg man besøker? Om man skal undersøke bruken, fokuserer man heller på selve alarmpanelet, og potensielt appen som følger med. 

Brukerens handlinger‍

Her fører man inn brukerreisen fra sluttbrukerens perspektiv. For å kartlegge denne delen, liker vi å gjennomføre en tjenestesafari. Da setter man seg selv i kundens sko og tester brukerreisen steg for steg. Hvilke konkrete handlinger må brukeren gjennom for å gjennomføre brukerreisen? Og er det noe underveis som oppleves tungvint? 

Si at vi skal kartlegge brukerreisen for bedriftsalarm: Hva skjer fra det punktet hvor et selskap vurderer å anskaffe alarm til kundeforholdet er aktivt, og hva skjer når det avsluttes? Hvordan fungerer alarmen, rent praktisk? Er det en app eller en nøkkelbrikke? Får alle de ansatte hver sin kode? Hva gjør en ansatt første gang de skal selv skru av eller på alarmen?  Hvem får beskjed hvis alarmen går? Og hvordan får de den beskjeden? Hvordan foregår off-boardingen om noen slutter?

Kontaktpunkter mot brukeren‍

Her kartlegger man mye av det samme som i raden over, bare at her vil man se på brukerreisen fra alarmselskapets og/eller underleverandørens perspektiv. For å kartlegge dette og funksjonene i de andre radene under, liker vi å gjøre dybdeintervjuer med de som jobber med de ulike aspektene av tjenesten vi skal undersøke. I eksemplet med bedriftsalarm kan dette for eksempel være de som jobber med salg og/eller kundeservice, de som installerer alarmene, de som jobber på nødsentralen og de som jobber med fakturering og betaling. Etter hvert som man begynner å kartlegge, vil man kanskje finne ut at det er flere involverte enn man trodde. Da bør man også intervjue disse.

Her vil man for eksempel finne ut: Hvordan møter brukeren leverandøren i de ulike stegene av brukerreisen? Kommer det noen på befaring der alarmen skal være? Kommer det en tekniker og installerer alarmen? Foregår kundekontakten over telefon, chat eller noe annet? Hvordan faktureres det? Hvordan får brukeren beskjed hvis alarmen har gått? Ringer det noen, eller får man et PUSH-varsel?

Usynlige konatktpunkter ‍

Dette handler om prosesser som må til for at brukerreisen skal gjennomføres, som brukeren selv ikke ser eller opplever direkte. For eksempel: Hvilke prosesser må til for å koble alarmen til de ulike brukerne av den? Hva skjer når det sendes ut en utrykning? Hva skjer hvis alarmpanelet må bytte batteri? Hvordan får teknikerne som skal installere alarmen vite hvilken alarm de skal installere hos de ulike kundene?‍

Støttefunksjoner‍

Hvilke støttefunksjoner trenger produktet eller tjenesten for å fungere? Dette kan for eksempel være nødvendig programvare knyttet til behandling av kundedata eller data fra alarmpanel, systemer for fakturering og betaling, CRM, analyseverktøy, systemer som er nødvendige for at alarmselskapet skal kunne kommunisere direkte med nødetatene etc. ‍

Rett opp i feilene‍

Etter hvert som man jobber seg gjennom de ulike aspektene ved brukerreisen, vil man mest sannsynlig avdekke hvor ting ikke går helt som man ønsker. 

Et eksempel fra vårt kontor: Appen vi bruker for å slå av alarmen, husker meg aldri som bruker. Den har ingen FaceID-login, så jeg må logge inn hver gang. Den husker heller ikke innloggingsdetaljene mine, så jeg må manuelt inn i passord-appen og hente ut dette for hver gang. Dette gjør at jeg blir stresset for å gå inn i bygget, for at alarmen skal gå og for at jeg skal måtte knote med alt dette. Så hadde de fulgt meg som bruker, hadde de sett at jeg sto utenfor kontoret og gjorde alt dette før jeg faktisk gikk inn. 

På andre siden av reisen, finner man kanskje ut at det er et problem at tidligere ansatte fortsetter å få PUSH-varsler fra alarmen lenge etter at de har sluttet på arbeidsplassen, og så finner man ut at dette styres av en bestemt programvare som behandler kundedata for de ulike bedriftskundene. Da er det mye som tyder på at man kanskje bør bytte programvare, eller lage en bedre prosess for off-boarding.

Når man har kartlagt friksjonspunktene i de ulike radene begynner moroa. Da må man komme med ideer på hvordan man kan eliminere friksjonen og forbedre tjenesten. For å gjøre dette kan man for eksempel bruke metoden ICE Scoring, for å bestemme hvillke ideer som bør implenenteres først. Først når forbedringene er implementert og den nye brukerreisen er testet og feilsøkt, er arbeidet ferdig – for denne gang.