Serviceplan

En tjänsteplan är ett diagram som kartlägger en kunds resa genom en tjänst tillsammans med allt som stöder den: de handlingar som är synliga för kunden, den personalaktivitet de kan se, den personalaktivitet de inte kan se, de interna processer som är involverade och de system som varje steg är beroende av. Den utökar en kundresekarta nedåt till den verksamhet som levererar tjänsten.

Dess struktur använder horisontella band separerade av definierade linjer. Kundåtgärder sitter överst. Under interaktionslinjen finns frontstage-åtgärder, vilket betyder personalaktivitet som kunden uppfattar. Under synlighetslinjen finns backstage-åtgärder, som stödjer tjänsten utan att synas. Under linjen för intern interaktion finns supportprocesser och system. Om man läser ett steg vertikalt visas allt som måste hända för att det ögonblicket ska fungera.

Det diagnostiska värdet kommer från den vertikala läsningen. När ett kundorienterat problem undersöks visar ritningen personalens åtgärder, processer och system under det, vilket ofta avslöjar att orsaken inte ligger där symtomet uppträder. En långsam respons vid ett tillfälle kan ha sitt ursprung i ett godkännandesteg tre lager längre ner; en agents oförmåga att svara på en fråga kan spåras till ett system som inte innehåller informationen.

Felpunkter och väntetider är de anteckningar som gör en ritning operativt användbar. Att markera var processen ofta går sönder, var överlämningar sker och var kunden väntar identifierar både de återställningsmekanismer som krävs och koncentrationen av förfluten tid. I de flesta tjänster står väntetiden mellan steg för en betydligt större del av den totala tiden än själva stegen, och detta är osynligt på en resekarta som bara registrerar åtgärder.

Att bygga en kräver input som designteamet inte har. Personalen i frontlinjen vet var processen faktiskt misslyckas och vilka lösningar som gör att den fungerar, driften känner till begränsningarna och tekniska team vet vad systemen kan och inte kan stödja. Ritningar som produceras utan dessa medarbetare beskriver processen som dokumenterad snarare än som utförd, och skillnaden mellan de två är vanligtvis var förbättringsmöjligheterna finns.

Artefakten tjänar flera målgrupper utöver design. Verksamheten använder den för att identifiera ineffektivitet och dubbelarbete, teknikteam använder den för att se vilka system som stöder vilka moment och var integrationsgap finns, och ledningen använder den för att förstå varför ett kundorienterat åtagande inte kan uppfyllas utan att något strukturellt ändras. Denna bredd är det som ger den mer organisatoriskt dragkraft än enbart en kundresekarta.

Ritningar är också användbara prospektivt snarare än bara diagnostiskt. Att ta fram en sådan för en tjänst som ännu inte existerar tvingar fram explicita beslut om vem som utför varje åtgärd, vilka system som måste tillhandahålla vilken information och var överlämningar kommer att ske, innan något av det byggs. Att medvetet utforma driften är betydligt billigare än att upptäcka under lanseringen att en utlovad kundupplevelse inte har någon process bakom sig.

Disciplin kring omfattning är nödvändig eftersom ritningar blir oanvändbara när de försöker täcka allt. En ritning över en betydande resa, med en konsekvent detaljnivå, är läsbar och handlingsbar. Att försöka sig på en hel tjänsteportfölj över alla varianter blir en väggbeklädnad som imponerar i en workshop och aldrig används efteråt. Att välja den resa med högst volym eller högst felfrekvens ger bättre avkastning än omfattande täckning.

Eftersom utdata vanligtvis identifierar förändringar i processer och system snarare än i gränssnitt, kräver det att man agerar utifrån det auktoritet utöver designfunktionen. I praktiken produceras ritningar genom UX revision och tjänstedesignarbete med bevis från användarundersökning inklusive personalintervjuer, och de systemberoenden de exponerar blir ofta en input till leveransplanen som upprätthålls av produktutveckling.