5.9 Servicedesign

Overblik og motivation

Servicedesign er praksissen at forme hele den service, et menneske oplever, på tværs af hver kanal og over hele tidsspændet, frem for en enkelt skærm eller app. Når nogen fornyer et pas, åbner en bankkonto eller anmelder en ødelagt gadelygte, oplever de ikke jeres produkt. De oplever en service: et telefonopkald, et websted, et brev med posten, en kø, en e-mail der aldrig kommer, en sagsbehandler der skal genindtaste deres oplysninger i et system, der ikke kan se, hvad webstedet allerede ved. Kapitel 5.1 dækker håndværket at designe individuelle grænseflader. Servicedesign zoomer ud til hele rejsen og til alt bag disken, der får forsiden af disken til at virke.

Det “bag disken”-skel er kernen i det. Servicedesign deler verden i frontstage, altså alt, brugeren ser og rører ved, og backstage, altså de mennesker, systemer og processer, der leverer servicen, men forbliver usynlige for brugeren. Gode frontstage-oplevelser fejler hele tiden, fordi backstage ikke kan understøtte dem. En flot bookingformular, der lander i et regneark, en ekspedient tjekker to gange om dagen, er en hurtig frontstage skruet på en langsom backstage, og brugeren mærker uoverensstemmelsen som tre dages stilhed. At designe hele servicen betyder at designe begge halvdele sammen og sømmene imellem.

For store teams er dette uundgåeligt et organisatorisk problem. Services spænder næsten altid over flere teams, afdelinger og systemer, og grænserne mellem disse ejere er netop der, hvor brugerens oplevelse falder fra hinanden. I virksomhedssammenhænge kan en enkelt kunderejse krydse salg, provisionering, fakturering og support, hver med sine egne værktøjer og mål og ingen ansvarlig for helheden. I det offentlige er indsatsen endnu højere: et menneske, der står over for en livsbegivenhed som et dødsfald eller en ny baby, skal navigere et dusin separate agenturer, der hver beder om den samme dokumentation, fordi tjenesterne er organiseret omkring regeringens struktur i stedet for personens behov. Servicedesign er, hvordan I får det hele til at hænge sammen for det menneske, der står i centrum.

Grundprincipper

Design hele servicen på tværs af kanaler og tid, ikke én skærm. Brugeren er ligeglad med, hvor jeres teamgrænser går.
Frontstage og backstage er ét system. En oplevelse er kun så god, som operationerne bagved kan bære.
Organisationsdiagrammet dukker op i servicen. Hvis teams er i siloer, vil servicen føles som siloer, så teamdesign og servicedesign må bevæge sig sammen.
Overdragelserne mellem kanaler og teams er der, hvor services går i stykker. Design sømmene lige så bevidst som trinnene.
Medarbejdervendte værktøjer er en del af servicen. En frustreret medarbejder med en dårlig konsol producerer en frustreret kunde.
Mål servicen fra ende til anden, fra brugerens første hensigt til deres reelle udfald, ikke én kanals lokale måling.
Organisér omkring brugerens mål eller livsbegivenhed, ikke jeres interne afdelinger.

Anbefalinger

Kortlæg kunderejsen på tværs af hver kanal

Begynd med at kortlægge den faktiske rejse, et menneske tager for at nå et udfald, som del af den bredere kundeoplevelse. Et kundeoplevelsesrejsekort udlægger de stadier, brugeren bevæger sig gennem, fra først at indse et behov til at nå sit mål og videre, og registrerer ved hvert stadie, hvad de forsøger at gøre, hvad de tænker og føler, og hvilken kanal de er i. Værdien kommer af at spænde over kanaler: de fleste reelle rejser hopper mellem et websted, en telefonlinje, en e-mail, en app og en fysisk lokation, og den værste smerte bor i hullerne mellem de kanaler, hvor kontekst går tabt, og brugeren må begynde forfra. Forankr kortet i research (kapitel 5.8) frem for i jeres antagelser, for den rejse, I forestiller jer, og den rejse, folk faktisk tager, er sjældent den samme. Markér “øjeblikkene, der betyder noget,” de få punkter, hvor oplevelsen afgørende lykkes eller fejler, og koncentrér jeres indsats der frem for at sprede den jævnt. En rejse, der ser glat ud på en enkelt kanal, kan stadig være elendig fra ende til anden, og kun tværkanalvisningen afslører det.

Byg en servicetegning, der forbinder frontstage med backstage

Disciplinens kerneartefakt er servicetegningen. Hvor et rejsekort tager brugerens synsvinkel, tilføjer en tegning lagene nedenunder. En typisk tegning løber i vandrette baner: kundens handlinger øverst, så de frontstage-berøringspunkter de interagerer med, så en “synlighedslinje”, under hvilken de backstage-handlinger sidder, medarbejdere foretager, og til sidst de understøttende systemer og processer, der muliggør alt ovenfor. Læs en kolonne oppefra og ned, og I kan se præcis, hvad der skal ske bag kulisserne for at ét frontstage-øjeblik virker, og hvor det vil gå i stykker, hvis et system er langsomt, eller en overdragelse er uklar. Tegninger er der, hvor I finder de stille fejl: den manuelle genindtastning, natbatchjobbet, teamet der ikke ved, at det er en afhængighed. Tegn dem med de driftsmedarbejdere, der faktisk kører backstage, ikke kun med designere, for de medarbejdere ved, hvor det rigtige arbejde sker. En tegning, der kun viser den lykkelige sti, er dekoration; tegn også fejl- og genopretningsstierne.

Design backstage og medarbejdervendte værktøjer som førsteklasses

Behandl de værktøjer, jeres medarbejdere bruger, som en del af produktet, for for kunden er de det. Når en callcenteragent, en sagsbehandler eller en lagerplukker kæmper med en langsom, grim, halvt ødelagt intern konsol, bliver den gnidning givet direkte videre til det menneske, de betjener, som længere ventetid, forkerte svar og synlig frustration. Interne værktøjer er kronisk underfinansierede netop fordi deres brugere er fastlåste og ikke kan gå, hvilket er præcis grunden til, at kapitel 5.1 advarer om, at software til fastlåste brugere betales i fejl og tabt produktivitet frem for frafald. Giv medarbejdervendte systemer den samme research, det samme design og den samme kvalitetsbarre, I giver kundevendte. Vær særligt opmærksomme på overdragelserne, de øjeblikke, hvor en sag passerer fra ét team, system eller kanal til et andet, fordi en tabt overdragelse er usynlig for alle undtagen brugeren, der venter. Design, hvad den modtagende side ser, hvilken kontekst der rejser med sagen, og hvad der sker, når overdragelsen fejler.

Afstem teamdesign med servicedesign

Forvent, at organisationsdiagrammet dukker op i servicen. Dette er Conways lov, iagttagelsen om at systemer kommer til at spejle kommunikationsstrukturerne i de organisationer, der bygger dem, dækket i dybden i kapitel 1.2. Hvis fire teams ejer fire trin af en rejse og sjældent taler sammen, vil brugeren føle fire usammenhængende trin med sprækker imellem. Så servicedesign og teamdesign er det samme problem set fra to vinkler, og I kan ikke rette en fragmenteret oplevelse blot med bedre skærme, hvis det underliggende ejerskab er fragmenteret. Brug jeres servicetegninger og rejsekort til at spørge, om jeres teams er tegnet omkring brugerens rejse eller omkring intern bekvemmelighed, og vær villige til at omforme teams eller skabe en rolle, der eksplicit ejer en rejse fra ende til anden, så nogen er ansvarlig for helheden og ikke blot deres skive. Når I ikke kan gentegne teams, så gør i det mindste overdragelserne mellem dem til eksplicitte kontrakter med aftalt kontekst og serviceniveauer.

Mål servicekvalitet fra ende til anden

Vælg målinger, der følger brugeren fra første hensigt til reelt udfald, ikke målinger, der smigrer én kanal isoleret. Et webteam kan ramme en gennemførelsesrate på 98 procent for formularer, mens en tredjedel af de gennemførelser stille fejler i en backstage-kø, og den lokale måling vil aldrig vise det. Mål gennemførelse fra ende til anden (fik personen faktisk, hvad de kom efter), tid fra ende til anden (hvor lang tid fra hensigt til udfald, inklusive de usynlige backstage-ventetider) og indsats (hvor svært det var, på tværs af alle de kanaler, de måtte bruge). Kombinér driftsdata med en direkte læsning af, hvordan det føltes, hvad enten det er gennem et transaktionelt spørgeskema, et spørgsmål i stil med Net Promoter Score eller løbende research. Hold især øje med frafaldet fra kanal til kanal, for disse sømme er der, hvor målt kvalitet og oplevet kvalitet afviger mest. Bind disse servicemålinger ind i produktstyringens udfaldssporing (kapitel 10.14), så tallene driver prioritering frem for at sidde i et dashboard, ingen handler på.

Afvejninger: fordele og ulemper

Tilgang	Fordele	Ulemper
Ejerskab af servicen fra ende til anden (ét team ejer en rejse)	Klar ansvarlighed, sammenhængende oplevelse, sømme bliver designet	Skærer på tværs af eksisterende organisationsstruktur, svært at bemande og finansiere, kan flaskehalse
Ejerskab pr. kanal eller pr. trin	Passer til eksisterende teams, klart lokalt omfang, let at bemande	Ingen ejer helheden; huller mellem kanaler; lokal optimering
Fuld servicetegning på forhånd	Afdækker backstage-fejl før de leveres, fælles forståelse	Tidskrævende, kan blive forældet, risiko for analyse før handling
Kun let kortlægning af kundeoplevelsesrejsen	Hurtig, billig, god nok til at få øje på de værste huller	Misser backstage- og systemfejl, en tegning ville fange
Omnikanal-ensartethed (samlet på tværs af kanaler)	Sømløse overdragelser, kontekst følger med på tværs af kanaler	Dyr integration, kræver delte data og afstemte teams

Den centrale spænding er mellem den service, brugeren har brug for, som flyder på tværs af jeres grænser, og den organisation, I faktisk har, som er tegnet langs dem. Løs den proportionalt frem for dogmatisk. I behøver ikke omorganisere hele virksomheden for at designe én service godt, men I har brug for mindst én person eller ét team, der er ansvarligt for udfaldet fra ende til anden, bevæbnet med en tegning, der gør backstage synlig, og et mandat til at rette sømmene. Brug jeres tungeste tegnearbejde på de rejser, der er højvolumen, højindsats eller højfejl, og brug lettere rejsekort til resten. Målet er ikke et perfekt artefakt; det er en service, der virker for det menneske, der står i centrum.

Spørgsmål til drøftelse med dit team

Hvem ejer hele servicen fra ende til anden, fra brugerens første hensigt til deres reelle udfald, og hvilken magt har vedkommende faktisk? I de fleste store organisationer er det ærlige svar “ingen,” fordi ejerskab er delt efter kanal og afdeling, og hver ejer måles på sin egen skive. Det hul er, hvor services fejler, da sømmene mellem ejere tilhører ingen og ikke får opmærksomhed. Beslut, om I vil skabe en eksplicit ejer fra ende til anden, en serviceejer eller rejseejer, og vær klare over, om den person faktisk kan ændre backstage-systemerne og teamgrænserne eller blot er ansvarlig for en måling, vedkommende ikke kan flytte. Tag jeres nuværende organisationsdiagram og jeres vigtigste rejses tegning med og læg dem side om side for at se, hvem der berører rejsen, og hvem der er ansvarlig for den. Hvis de to ikke stemmer overens, har I fundet kilden til jeres værste overdragelsesfejl. Svaret bør ændre, hvordan I finansierer og bemander arbejdet, ikke blot hvem der deltager i standuppen.
Er vores teams tegnet omkring brugerens rejse eller omkring vores interne bekvemmelighed, og er vi villige til at ændre det? Conways lov (kapitel 1.2) betyder, at jeres service vil spejle jeres kommunikationsstruktur, uanset om I vil det eller ej, så en rejse delt over fire ukommunikative teams vil føles som fire usammenhængende trin. Det bekvemme træk er at rette skærmene og lade organisationsdiagrammet være, men det behandler et symptom, mens årsagen bliver ved med at regenerere det. Se ærligt på, om jeres teamgrænser skaber netop de overdragelseshuller, jeres brugere klager over, og vej den reelle omkostning ved at omforme teams mod den løbende omkostning ved en fragmenteret oplevelse. Tag smertepunkterne fra jeres rejsekort med og tjek, hvor mange der sidder præcis på en teamgrænse. Hvis de fleste gør, vil bedre UI ikke redde jer, og samtalen må handle om teamdesign. Det, I beslutter her, afgør, om jeres serviceforbedringer holder, eller stille eroderer.
Hvor godt tjener vores medarbejdervendte værktøjer de mennesker, der bruger dem, og hvordan viser det sig for kunden? Interne værktøjer er den mest pålideligt forsømte software i enhver stor organisation, fordi deres brugere er fastlåste og deres budgetter er eftertanker, og alligevel giver en sagsbehandler eller agent, der kæmper med en ødelagt konsol, den gnidning direkte videre til kunden som forsinkelser og fejl. Spørg, hvornår I sidst lavede research på jeres egne medarbejdervendte systemer, eller om I antager, at fordi medarbejdere får løn for at klare sig, er værktøjerne fine. Overvej, at backstage er der, hvor de fleste stille servicefejl faktisk sker, i den manuelle genindtastning og den tabte kontekst ved overdragelser, hvoraf intet kan ses af frontstage-målinger. Tag en rigtig medarbejder med ind i rummet og se vedkommende gennemføre en almindelig opgave, og spor så, hvordan deres kamp når kunden. Hvis I aldrig har finansieret interne værktøjer som et produkt, er det sandsynligvis jeres billigste store forbedring af servicekvaliteten fra ende til anden.
Hvilken enkelt måling fra ende til anden ville fortælle os, om hele servicen faktisk virker, og hvorfor følger vi den ikke i dag? For et stort team er dette spørgsmål ubehageligt, fordi det ærlige svar som regel er, at hver kanal og afdeling har en grøn lokal måling, mens ingen måler, om personen fik, hvad de kom efter. Formulargennemførelsesrater, opkaldshåndteringstider og antal lukkede sager smigrer alle den ejer, der rapporterer dem, og hver kan forblive sund, mens det sammenhængende udfald fejler i en backstage-kø. Beslut en gennemførelses- eller tidsmåling fra ende til anden, der følger brugeren fra første hensigt til reelt udfald, og vær klare over, hvem der vil instrumentere den på tværs af systemer, der aldrig blev bygget til at dele data. Tag de nuværende dashboards pr. kanal, en tegning af en højvolumenrejse og et estimat af det stille frafald mellem kanaler med, så hullet mellem lokalt grønt og rødt fra ende til anden er synligt. I virksomheds- og offentlige sammenhænge aftal, hvem der er ansvarlig for tallet for hele rejsen, og hvem der har autoritet til at handle på det, for en måling, ingen enkelt ejer kan flytte, er en måling, der ikke ændrer noget.
Hvor tvinger vores service brugeren til at gentage sig selv, og hvad ville en “fortæl os det én gang”-version koste at bygge? Duplikeret dataindsamling er det klareste signal om, at en service er organiseret omkring jeres interne grænser frem for brugerens behov, og den er dyr på begge sider: brugeren genindtaster den samme dokumentation ved hver overdragelse, og hver afdeling betaler for at genindsamle og genverificere den. Det modstridende hensyn er, at den fælles post, der gør “fortæl os det én gang” mulig, kræver integration på tværs af systemer og teams, der måske ingen historie har med at stole på hinandens data, så byggeomkostningen og datastyringsarbejdet er reelle. Tag et rejsekort annoteret med hvert punkt, hvor brugeren leverer oplysninger, I allerede har, og en grov optælling af, hvor mange separate poster der gemmer det samme felt, med. For en offentlig tjeneste, der spænder over flere agenturer, så tilføj retsgrundlaget for at dele de data mellem dem, da samtykke, privatlivslov og informationsstyringsregler afgør, om “fortæl os det én gang” overhovedet er tilladt, før I spørger, om det er overkommeligt.
Når kontekst overdrages mellem et team, et system eller en kanal, hvad rejser der faktisk med sagen, og hvad sker der, når overdragelsen fejler? Overdragelser er der, hvor services går stille i stykker, fordi fejlen er usynlig for alle undtagen brugeren, der venter, og i en stor organisation krydser hver overdragelse en grænse, hvor ingen enkelt ejer føler sig ansvarlig for det, der tabes. Beslut bevidst, hvilke data, hvilken historik og hvilken status der skal følge med en sag, om den modtagende side kan se det, og hvad genopretningsstien er, når en overførsel går i stå eller ankommer ufuldstændig. Tag jeres servicetegning for en reel rejse med og spor hver linje, hvor sagen skifter hænder, og markér, hvilken kontekst der bevares, og hvad der genindtastes eller tabes. I virksomheds- og offentlige tjenester bundet af serviceniveauaftaler eller lovbestemte svartider så behandl hver overdragelse som en eksplicit kontrakt med aftalt kontekst og en defineret fallback, for en udokumenteret overdragelse er et brud, der venter på at ske, som intet dashboard vil advare jer om.

Sektorperspektiv

Startup. Med en håndfuld mennesker og ingen tid til omfattende artefakter så tegn kun den ene rejse, der bærer jeres kerneværdi, og tegn lige nok af den til at se, hvor frontstage overdrager til en langsom eller manuel backstage. Gør det på et whiteboard på en eftermiddag, ikke som en seks ugers undersøgelse. Jeres fordel er, at hele servicen bor i nogle få hoveder, så at rette en ødelagt overdragelse er en samtale frem for en forhandling på tværs af afdelinger. Brug den fordel, før I vokser de grænser, der gør overdragelser dyre.

Lille virksomhed. I har ingen servicedesigner og intet budget til en, så det praktiske træk er at gå jeres egen rejse som kunde, notere hvert punkt, hvor I får nogen til at gentage sig eller vente på et manuelt trin, og rette det værste. Foretræk værktøjer, der allerede forbinder jeres kanaler (en fælles indbakke, et bookingsystem der underretter medarbejdere), frem for at bygge integration, I ikke kan vedligeholde. Når I køber et system, så vej, hvor godt det overdrager kontekst til næste trin, for et billigt værktøj, der taber kundens oplysninger mellem salg og levering, koster jer mere i tabt gentagen forretning, end det sparer.

Stor virksomhed. Kerneproblemet er, at en enkelt rejse krydser salg, provisionering, fakturering og support, hver med grønne lokale målinger og ingen ansvarlig for helheden. Invester i fulde servicetegninger for jeres højvolumen- og højindsatsrejser, udpeg en navngiven ejer fra ende til anden med autoritet over sømmene, og standardisér en måling fra ende til anden, der overlever revision og driver prioritering på tværs af teams. Behandl den fælles sagspost og de medarbejdervendte konsoller som finansierede produkter, og gør hver overdragelse på tværs af teams til en eksplicit kontrakt med aftalt kontekst og serviceniveauer.

Offentlig sektor. Tjenester skal organiseres omkring borgerens livsbegivenhed, ikke agenturets struktur, og holdes til offentliggjorte servicestandarder med åbenhed og offentlig ansvarlighed. Indkøbsregler former, hvad I kan bygge, så foretræk fælles poster og “fortæl os det én gang”-mønstre, hvor retsgrundlaget for datadeling findes, og dokumentér det grundlag, før I designer flowet. Research med rigtige brugere, herunder de mest sårbare, tegn den tværgående backstage hos flere agenturer, og mål hele rejsen frem for hvert agenturs skive, fordi offentligheden bedømmer servicen på, om de fik udfaldet, ikke på hvilken afdeling der lykkedes.

Eksempler

Startup. Et startup på ti personer, der solgte et husforsikringsprodukt, tænkte på sig selv som et appfirma, og dets app var reelt god. Men frafaldet var højt, og supporten druknede, så grundlæggerne tegnede den faktiske skadesrejse. De fandt, at den reelle service var det øjeblik, en kunde havde et sprunget rør ved midnat: appen overdrog til en e-mailkø, som overdrog til en tredjepartstaksator, kunden ikke kunne se, som ringede tilbage i arbejdstiden fra et ukendt nummer, der gik til telefonsvarer. Den polerede frontstage sad oven på en langsom, uigennemsigtig backstage, og “øjeblikket, der betyder noget,” en stresset skade, var præcis der, hvor den fejlede. At rette overdragelserne, give kunden synlighed i taksatortrinnet og behandle skadesarbejdsgangen som en del af produktet gjorde mere for fastholdelsen end nogen ny appfunktion.

Stor virksomhed. Et telekommunikationsfirma solgte erhvervsinternet med en bestilling online på to minutter og et leveringsmareridt på to uger. Salg, provisionering, feltteknikere og fakturering ejede hver en strækning af rejsen og ramte hver deres egne mål, mens kunden oplevede gentagne anmodninger om de samme oplysninger, misserede aftalevinduer og en første regning, der ikke svarede til tilbuddet. Servicetegning på tværs af alle fire afdelinger afslørede sømmene: kontekst døde ved hver overdragelse, fordi ingen fælles post af ordren fulgte kunden igennem. Virksomheden udpegede en ejer af ordre-til-aktivering fra ende til anden, byggede en fælles sagspost, der rejste med ordren, og omkablede teamincitamenter omkring det sammenhængende udfald. Lokale målinger ændrede sig næsten ikke; aktiveringstiden fra ende til anden og klageraten faldt begge kraftigt.

Offentlig sektor. En national regering redesignede sin “et familiemedlems død”-tjeneste, en af de sværeste livsbegivenheder, en borger står over for. Tidligere måtte den efterladte separat underrette skattemyndigheden, pensionstjenesten, køretøjsagenturet, pasmyndigheden og lokalregeringen, hver med sin egen formular og hver med krav om den samme dødsattest. Ved at organisere servicen omkring livsbegivenheden frem for agenturerne byggede teamet en enkelt “fortæl os det én gang”-rejse, der tog de oplysninger, en person indtastede, og fordelte dem til hver relevant afdeling bag synlighedslinjen. Afstemt til den offentlige sektors servicestandard researchede de med nyligt efterladte, tegnede den tværgående backstage hos flere agenturer og målte hele rejsen frem for hvert agenturs del. Gennemførelsen steg, duplikeret kontakt faldt, og borgere behøvede ikke længere gennemleve et dødsfald et dusin gange.

Business case: motivation, ROI og TCO

Afkastet af servicedesign kommer af at lukke hullerne mellem kanaler og teams, fordi det er der, værdi lækker ud. Fejl fra ende til anden er dyre på måder, som dashboards pr. kanal skjuler: en rejse, der gennemføres online, men fejler i backstage, genererer en supportkontakt, en omgørelse og ofte en tabt kunde, og ingen af de omkostninger lander på den kanal, der ser vellykket ud. Når I måler og retter hele servicen, reducerer I duplikeret indsats (de samme data indfanget fem gange), fejlefterspørgsel (kontakter forårsaget alene af, at servicen svigtede første gang) og frafald fra oplevelser, der føltes ødelagte, selv når hver del teknisk virkede. I virksomheder viser gevinsten sig som kortere ordre-til-kontanter-cyklusser og færre eskaleringer; i det offentlige viser den sig som lavere omkostning ved at betjene og højere vellykket gennemførelse af tjenester, folk ikke kan få andre steder.

De totale ejeromkostninger må veje omkostningen ved at lave servicedesign mod den langt større omkostning ved den fragmentering, I allerede bærer. De synlige omkostninger er research, tegning, koordinering på tværs af teams og nogle gange investeringen i fælles systemer og medarbejderværktøjer. De skjulte omkostninger ved ikke at gøre det er spredt over supportbudgetter, drift og omdømmeskade, hvilket netop er grunden til, at ledelsen undervurderer dem: intet enkelt teams budget viser den fulde pris for en ødelagt overdragelse. For at føre sagen så sæt et tal på fejlefterspørgsel og duplikeret arbejde i én højvolumenrejse, tegn den, og vis ledelsen, hvor stor en del af omkostningen der sidder i sømmene mellem deres eksisterende teams. Kør så en afgrænset pilot på den rejse, mål fra ende til anden før og efter, og brug resultatet til at argumentere for de sværere strukturelle ændringer. At ramme servicedesign ind som fjernelsen af omkostninger, der allerede betales, bare usynligt, plejer at bevæge økonomi- og styringsinteressenter mere end nogen appel til elegance.

Anti-mønstre og faldgruber

Kanaløer. Hver kanal designes og måles for sig, så rejsen ser fin ud overalt og virker ingen steder fra ende til anden.
Frontstage-læbestift. En poleret UI skruet på en langsom eller manuel backstage, så oplevelsen går i stykker i det øjeblik, brugeren har brug for, at backstage svarer.
Organisationsdiagram som service. Tjenester struktureret omkring jeres afdelinger i stedet for brugerens mål, hvilket tvinger brugeren til at navigere jeres interne grænser.
Tegneteater. Omfattende tegninger tegnet én gang, beundret og aldrig brugt til at ændre, hvordan servicen faktisk kører.
Kortlægning kun af den lykkelige sti. Rejser og tegninger, der ignorerer fejl og genopretning, hvilket er der, hvor reelle services gør ondt.
Forsømte medarbejderværktøjer. At behandle interne, medarbejdervendte systemer som andenrangs, så deres gnidning lækker direkte igennem til kunden.
Overdragelsesamnesi. Kontekst tabt ved hver overførsel mellem team, system eller kanal, så brugeren forklarer sin situation igen og igen.
Målinger, der smigrer. Lokale mål pr. kanal, der forbliver grønne, mens udfaldet fra ende til anden stille fejler.

Modenhedsmodel

Niveau 1, Opstart: Hver kanal og hvert team designes og køres isoleret, reaktivt. Ingen ejer servicen fra ende til anden, der er intet rejsekort eller ingen tegning, og backstage-fejl forbliver usynlige, til de dukker op som klager. Brugere gentager rutinemæssigt sig selv på tværs af kanaler, fordi ingen har set på helheden.
Niveau 2, Udvikling: Nogle rejser er kortlagt, og de værste tværkanalhuller er kendt, men praksissen er pletvis og afhænger af individuel entusiasme. Rejsekort findes, men når sjældent backstage, ejerskab er stadig pr. kanal, medarbejdervendte værktøjer er en eftertanke, og hvor der tegnes, varierer det fra team til team.
Niveau 3, Standardisering: Nøglerejser tegnes frontstage til backstage med driftsmedarbejdere, med en dokumenteret metode anvendt ensartet i hele organisationen. Navngivne serviceejere er ansvarlige fra ende til anden, overdragelser er eksplicitte kontrakter med aftalt kontekst, medarbejderværktøjer designes bevidst, og tilgangen er håndhævet frem for valgfri.
Niveau 4, Styring: Servicen måles og styres med data. Gennemførelse fra ende til anden, tid fra ende til anden (inklusive usynlige backstage-ventetider), brugerindsats, fejlefterspørgsel og frafald fra kanal til kanal følges mod baselines, og overdragelsesfejl og duplikeret dataindsamling kvantificeres frem for antages. Tegninger holdes aktuelle, serviceejere holdes til mål fra ende til anden, og go/no-go-beslutninger om ændringer hviler på den dokumentation i stedet for på lokale kanalmålinger.
Niveau 5, Orkestrering: Teamdesign og servicedesign er afstemt, så ejerskab følger rejsen, og organisationen er struktureret omkring brugermål og livsbegivenheder frem for afdelinger. Målinger fra ende til anden driver prioritering, organisationen tegner, måler og omformer løbende både oplevelse og drift sammen, og den tilpasser hele servicen, efterhånden som brugerbehov, kanaler og grænser på tværs af teams skifter.

Idéer til drøftelse

Når en rejse krydser flere teams, er det så bedre at udpege én ejer fra ende til anden eller at gentegne teams omkring rejsen, og hvad afgør valget?
Hvor meget af jeres servicekvalitet kan rettes med bedre frontstage-design, og hvor meget kræver at ændre backstage eller organisationsdiagrammet?
Hvor i jeres service må brugere oftest gentage sig selv, og hvad ville en “fortæl os det én gang”-version koste at bygge?
Hvordan finansierer og prioriterer I medarbejdervendte værktøjer, når deres brugere er fastlåste og ikke kan stemme med fødderne?
Bør tjenester organiseres omkring livsbegivenheder eller brugermål, selv når det skærer direkte imod jeres finansierings- og rapporteringslinjer?
Hvilken enkelt måling fra ende til anden ville bedst fortælle jer, om hele jeres service virker, og hvorfor følger I den ikke i dag?

Vigtigste pointer

Design hele servicen på tværs af kanaler og over tid, ikke én skærm, og husk at brugeren er ligeglad med, hvor jeres teamgrænser falder.
Frontstage og backstage er ét system; en fantastisk oplevelse er kun så god, som operationerne bagved kan bære.
Servicetegningen er jeres kerneartefakt: den forbinder frontstage-berøringspunkter med de backstage-mennesker, -systemer og -overdragelser, der leverer dem.
Organisationsdiagrammet dukker op i servicen (Conways lov), så servicedesign og teamdesign må bevæge sig sammen.
Behandl medarbejdervendte værktøjer og overdragelserne mellem teams som førsteklasses dele af servicen, fordi deres gnidning når kunden.
Mål servicen fra ende til anden, fra første hensigt til reelt udfald, og organisér omkring brugerens mål eller livsbegivenhed frem for jeres afdelinger.

Referencer og videre læsning

Marc Stickdorn and Jakob Schneider, This Is Service Design Thinking
Marc Stickdorn, Markus Edgar Hormess, Adam Lawrence, and Jakob Schneider, This Is Service Design Doing
Andy Polaine, Lavrans Lovlie, and Ben Reason, Service Design: From Insight to Implementation
Lynn Shostack, “Designing Services That Deliver,” Harvard Business Review
Matthew Skelton and Manuel Pais, Team Topologies
Melvin Conway, “How Do Committees Invent?“, Datamation
UK Government Digital Service, Service Manual and the Service Standard
U.S. General Services Administration, 18F Methods and the U.S. Digital Service Playbook
Nielsen Norman Group, articles on service blueprinting and customer journey mapping