Serviceplan

En serviceplan er et diagram, der kortlægger en kundes rejse gennem en service sammen med alt, der understøtter den: de handlinger, der er synlige for kunden, den medarbejderaktivitet, de kan se, den medarbejderaktivitet, de ikke kan se, de involverede interne processer og de systemer, som hvert trin afhænger af. Den udvider et kunderejsekort nedad i den operation, der leverer servicen.

Dens struktur bruger vandrette bånd adskilt af definerede linjer. Kundehandlinger er øverst. Under interaktionslinjen er der frontstage-handlinger, hvilket betyder medarbejderaktivitet, som kunden opfatter. Under synlighedslinjen er der backstage-handlinger, som understøtter tjenesten uden at blive set. Under linjen for intern interaktion er der supportprocesser og -systemer. Hvis man læser et trin lodret, vises alt, hvad der skal ske, for at det øjeblik fungerer.

Den diagnostiske værdi kommer fra den vertikale aflæsning. Når et kundeorienteret problem undersøges, viser blueprinten medarbejdernes handlinger, processer og system under det, hvilket ofte afslører, at årsagen ikke er der, hvor symptomet opstår. En langsom reaktion på et tidspunkt kan stamme fra et godkendelsestrin tre lag længere nede; en agents manglende evne til at besvare et spørgsmål kan spores tilbage til et system, der ikke indeholder informationen.

Fejlpunkter og ventetider er de annotationer, der gør en blueprint operationelt nyttig. Markering af, hvor processen ofte afbrydes, hvor overleveringer finder sted, og hvor kunden venter, identificerer både de nødvendige genoprettelsesmekanismer og koncentrationen af ​​forløbet tid. I de fleste tjenester tegner ventetid mellem trin sig for langt mere af den samlede varighed end selve trinnene, og dette er usynligt på et rejsekort, der kun registrerer handlinger.

At bygge en kræver input, som designteamet ikke har. Frontlinjepersonalet ved, hvor processen rent faktisk fejler, og hvilke løsninger der holder den i gang, driften kender begrænsningerne, og tekniske teams ved, hvad systemerne kan og ikke kan understøtte. Blueprints produceret uden disse bidragydere beskriver processen som dokumenteret snarere end som udført, og forskellen mellem de to er normalt, hvor forbedringsmulighederne ligger.

Artefaktet tjener flere målgrupper ud over design. Driftsafdelinger bruger det til at identificere ineffektivitet og dobbeltarbejde, teknologiteams bruger det til at se, hvilke systemer der understøtter hvilke øjeblikke, og hvor integrationshuller er, og ledelsen bruger det til at forstå, hvorfor en kundeorienteret forpligtelse ikke kan opfyldes uden at ændre noget strukturelt. Denne bredde er det, der giver det mere organisatorisk fremdrift end et kunderejsekort alene.

Blueprints er også nyttige prospektivt snarere end kun diagnostisk. At producere en blueprint til en tjeneste, der endnu ikke eksisterer, tvinger eksplicitte beslutninger om, hvem der udfører hver handling, hvilke systemer der skal levere hvilke oplysninger, og hvor overdragelser vil finde sted, før noget af det er bygget. At designe driften bevidst er betydeligt billigere end at opdage under lanceringen, at en lovet kundeoplevelse ikke har nogen proces bag sig.

Disciplin i omfang er nødvendig, fordi tegninger bliver ubrugelige, når de forsøger at dække alt. En tegning af én betydelig rejse, med et ensartet detaljeringsniveau, er læsbar og handlingsrettet. Et forsøg på at implementere en hel serviceportefølje på tværs af alle varianter bliver en vægbeklædning, der imponerer i et værksted og aldrig bruges bagefter. At vælge rejsen med det højeste volumen eller den største fejlrate giver bedre afkast end omfattende dækning.

Fordi outputtet typisk identificerer ændringer i processer og systemer snarere end i grænseflader, kræver det autoritet ud over designfunktionen at handle på det. I praksis produceres tegninger gennem UX-revision og servicedesignarbejde med evidens fra brugerundersøgelser herunder medarbejderinterviews, og de systemafhængigheder, de afdækker, bliver ofte et input til den leveringsplan, der holdes af produktudvikling.