6 vragen om voorbereid een Service blueprint sessie te organiseren

Voordat je head first in de organisatie van een Service blueprint sessie duikt is het verstandig om helder te krijgen welk probleem je op wil lossen. Daarvoor kan je een aantal vragen stellen. Dit blog artikel loopt mogelijke vragen na zodat je je als designer beter kan voorbereiden voor de Service blueprint sessie.

Een Service blueprint is een tool waarmee interne bedrijfsprocessen gevisuealiseerd kunnen worden. Het perspectief van de klant is minstens zo belangrijk als de interne bedrijfsprocessen. Zonder perspectief van de klant zou het een proces document worden. Service blueprint kenmerkt zich door het co-creatieve karakter van de sessie waarin het gemaakt wordt.

Het is belangrijk om de juiste mensen in zo’n sessie te betrekken omdat zij specifieke kennis hebben over een mogelijk belangrijk touchpoint.

Een Service blueprint sessie betekenis geven klinkt makkelijker dan het is. Voordat je zo’n sessie op touw zet is is het verstandig om de volgende vragen te beantwoorden; wat is het doel van de Service Blueprint? Wie nodig je uit? Wat hangt er aan het eind van de sessie? Welke aannames heb je? Wat zijn nu de echte problemen? Welke beschikbare data heb je over de gebruiker? En stel verder alle vragen die je zelf ook belangrijk acht.

Het kan zijn het beantwoorden van de vragen lastig is. In dat geval is het verstandig je af te vragen of een Service blueprint sessie wel het juiste middel is.

Wat is het doel?

Wat hoop je aan het einde van een Service blueprint sessie beantwoord te krijgen? Als je van tevoren duidelijk maakt welk doel je voor ogen hebt dan zal de sessie soepeler verlopen. Doelen kunnen zijn:

  • klantervaring verbeteren door interne processen bloot te leggen
  • samenwerking tussen teams bevorderen
  • een touchpoint digitaliseren

Wie nodig je uit?

Welke stakeholders betrek je bij de sessie? Verstandig is om mensen uit te nodig die intern invloed kunnen uitoefen op onderdelen van de customer journey. Denk bijvoorbeeld aan:

  • Product owners
  • Developers
  • Managers
  • Klantenservice medewerkers
  • etc.

Als het gaat om een klein bedrijf kan je ook denken aan

  • De eigenaar
  • Marketing manager
  • etc.

Tijdens de sessie kan ook blijken dat sommige vragen niet beantwoord kunnen worden doordat de juiste persoon niet aanwezig is. In zo’n geval zoek ik de mensen op om er met hen nog eens doorheen te lopen.

Wat hangt er aan het eind van de sessie?

Deze vraag dwingt mij om na te denken over het verloop van de sessie. Wat wil ik aan het eind bereikt hebben, hoe ziet dat er uit? Zelf voer ik vaak een gedachte experiment uit.

Ik stel mezelf voor in de ruimte met brownpaper en stakeholders. Door na te denken over de handelingen die ik uit wil voeren tijdens de sessie anticipeer ik op mogelijke hordes die voor kunnen komen. Door deze hordes denkbeeldig alvast te nemen kan ik controleren of mijn aanpak logisch is. Het werkt voor mij als een soort generale repetitie.

Welke aannames heb je?

Ik heb idee├źn, overtuigingen of verwachtingen die ongevalideerd zijn. Deze kunnen berusten op vooroordelen, persoonlijke ervaringen of vermoedens. Dat is niet erg maar het is wel erg als er een zeker risico kleeft en ik (onbewust) voortbouw op een aanname.

Voorbeeld van een aanname: doordat twee teams niet goed samenwerken moet een klant onnodig lang wachten voordat deze een product in ontvangst kan nemen.

Het risico is dat de Service blueprint sessie wordt ingestoken vanuit het idee dat de samenwerking verbeterd moet worden tussen de teams. Ik neem niet weg dat dit een belangrijk gevolg kan zijn van de sessie. Het belangrijkste is echter dat de aandacht uit moet gaan naar de klant. Wat ervaart de klant precies? En welke stappen worden en binnen het bedrijf gezet? Op die manier komt vanzelf de samenwerking tussen de teams naar boven drijven.

Voordat je een sessie begint vanuit een probleem die je denkt te zien is het aan te raden om je aanname dubbel te checken. Ook verstandig om het doel dat je voor ogen hebt met de sessie scherp te houden.

Wat zijn nu de echte problemen?

Voortbordurend op het stukje over aannames. Hoe lang is de klant aan het wachten op het product? Is dat echt erg? Is er bewijs voor het probleem?Welk probleem probeer je op te lossen? Dit zijn veel subvragen, deze beantwoord krijgen zorgt ervoor dat je kan starten met een gefundeerd probleem. Stakeholders zullen dit waarderen en de Blueprint sessie wordt er een stuk duidelijker door.

Welke beschikbare data is er?

Om een probleem te beschrijven heb je wel data nodig. Dit kan kwalitatieve of kwantitatieve data zijn. Zolang het maar kan bijdragen aan het mogelijke probleem. Ik vind het prettig om flink veel data te verzamelen en ook met klanten te bellen om erachter te komen hoe zij een service hebben ervaren. Als ik aan de hand van die data kan aantonen dat er een probleem is ben ik blij.

Conclusie

Een Service blueprint sessie is nuttig als van tevoren duidelijk is wat je wil bereiken. Om dat helder te krijgen kan je verschillende vragen stellen. Het kan ook blijken dat een Service blueprint sessie niet geschikt is. Formuleer je probleem helder en duidelijk, als dat gelukt is ben je klaar voor de volgende stap. De sessie organiseren.

Bron verantwoording:

Bij het schrijven van dit blog artikel heb ik, naast mijn eigen ervaring, gebruik gemaakt van meerdere bronnen, namelijk:

Auteur: Sabrina Doornekamp

Ik heb een achtergrond in grafische vormgeving en heb media en cultuur gestuurd aan de Universiteit van Amsterdam. Mijn specialisatie richtte zich op digitale media. Samen vormen deze studies de basis voor mijn interesse in digitale systemen en hun gebruikers. Ik geloof dat samenwerking en communicatie belangrijke onderdelen zijn van het ontwerpproces.