5.9 Tjänstedesign

Översikt och motivation

Tjänstedesign är praxisen att forma hela den tjänst en person upplever, över varje kanal och över hela tidsspannet, snarare än en enskild skärm eller app. När någon förnyar ett pass, öppnar ett bankkonto eller anmäler en trasig gatlykta upplever de inte din produkt. De upplever en tjänst: ett telefonsamtal, en webbplats, ett brev i posten, en kö, ett e-postmeddelande som aldrig kommer, en handläggare som måste knappa in sina uppgifter på nytt i ett system som inte kan se vad webbplatsen redan vet. Kapitel 5.1 behandlar hantverket att designa enskilda gränssnitt. Tjänstedesign zoomar ut till hela resan och till allt bakom disken som får fronten av disken att fungera.

Den skillnaden “bakom disken” är själva kärnan. Tjänstedesign delar världen i scenen (front-stage), det vill säga allt användaren ser och rör vid, och kulisserna (back-stage), det vill säga de människor, system och processer som levererar tjänsten men förblir osynliga för användaren. Goda upplevelser på scenen misslyckas hela tiden för att kulisserna inte kan bära dem. Ett snyggt bokningsformulär som landar i ett kalkylblad en tjänsteman kontrollerar två gånger om dagen är en snabb scen påskruvad på långsamma kulisser, och användaren känner missmatchen som tre dagars tystnad. Att designa hela tjänsten betyder att designa båda halvorna tillsammans, och sömmarna mellan dem.

För stora team är detta oundvikligen ett organisatoriskt problem. Tjänster spänner nästan alltid över flera team, avdelningar och system, och gränserna mellan dessa ägare är exakt där användarens upplevelse faller samman. I företagsmiljöer kan en enda kundresa korsa försäljning, leverans, fakturering och support, var och en med egna verktyg och mål och ingen ansvarig för helheten. I myndigheter är insatserna ännu högre: en person inför en livshändelse som en bortgång eller ett nytt barn måste navigera ett dussin separata myndigheter, var och en ber om samma belägg, eftersom tjänsterna är organiserade kring statens struktur i stället för personens behov. Tjänstedesign är hur du får hela saken att hänga ihop för människan i dess mitt.

Nyckelprinciper

Designa hela tjänsten över kanaler och tid, inte en skärm. Användaren bryr sig inte om var dina teamgränser går.
Scen och kulisser är ett system. En upplevelse är bara så bra som verksamheten bakom den kan bära.
Organisationsschemat syns i tjänsten. Om team är isolerade kommer tjänsten att kännas isolerad, så teamdesign och tjänstedesign måste röra sig tillsammans.
Överlämningarna mellan kanaler och team är där tjänster går sönder. Designa sömmarna lika medvetet som stegen.
Verktyg för personalen är en del av tjänsten. En frustrerad handläggare med en dålig konsol producerar en frustrerad kund.
Mät tjänsten från början till slut, från användarens första avsikt till deras verkliga utfall, inte en kanals lokala mått.
Organisera kring användarens mål eller livshändelse, inte kring dina interna avdelningar.

Rekommendationer

Kartlägg kundresan över varje kanal

Börja med att kartlägga den faktiska resa en person tar för att nå ett utfall, som en del av den bredare kundupplevelsen. En kundresekarta lägger ut de stadier användaren rör sig genom, från första insikten om ett behov till att nå sitt mål och därefter, och registrerar vid varje stadium vad de försöker göra, vad de tänker och känner och vilken kanal de befinner sig i. Värdet kommer av att spänna över kanaler: de flesta verkliga resor hoppar mellan en webbplats, en telefonlinje, ett e-postmeddelande, en app och en fysisk plats, och den värsta smärtan bor i luckorna mellan dessa kanaler, där kontext går förlorad och användaren måste börja om. Förankra kartan i forskning (kapitel 5.8) snarare än i dina antaganden, eftersom resan du föreställer dig och resan människor faktiskt tar sällan är densamma. Markera “ögonblicken som spelar roll”, de få punkter där upplevelsen avgörande lyckas eller misslyckas, och koncentrera din insats där snarare än att sprida den jämnt. En resa som ser smidig ut på en enskild kanal kan ändå vara eländig från början till slut, och bara kanalövergripande vy avslöjar det.

Bygg en tjänstritning som länkar scen till kulisser

Disciplinens kärnartefakt är tjänstritningen (service blueprint). Där en kundresekarta tar användarens vy lägger en ritning till lagren under. En typisk ritning löper i horisontella banor: kundens handlingar överst, sedan de kontaktpunkter på scenen de interagerar med, sedan en “synlighetslinje” under vilken de handlingar personalen utför i kulisserna sitter och slutligen de stödsystem och processer som möjliggör allt ovanför. Läs en kolumn uppifrån och ned och du kan se exakt vad som måste hända bakom kulisserna för att ett ögonblick på scenen ska fungera, och var det går sönder om ett system är långsamt eller en överlämning är suddig. Ritningar är där du hittar de tysta felen: den manuella ominmatningen, nattbatchen, teamet som inte vet att det är ett beroende. Rita dem med de driftmedarbetare som faktiskt kör kulisserna, inte bara med designers, eftersom dessa vet var det verkliga arbetet sker. En ritning som bara visar den glada vägen är dekoration. Rita också upp fel- och återhämtningsvägarna.

Designa kulisserna och verktygen för personalen som förstklassiga

Behandla de verktyg din personal använder som en del av produkten, eftersom de för kunden är det. När en callcenteragent, en handläggare eller en lagerplockare kämpar mot en seg, ful, halvtrasig intern konsol skickas den friktionen rakt vidare till personen de betjänar, som längre väntetider, fel svar och synlig frustration. Interna verktyg är kroniskt underfinansierade just för att deras användare är fångade och inte kan gå, vilket är exakt varför kapitel 5.1 varnar för att programvara för fångade användare betalas i fel och förlorad produktivitet snarare än avhopp. Ge system för personalen samma forskning, design och kvalitetsribba som ni ger kundvända. Var särskilt uppmärksam på överlämningarna, ögonblicken då ett ärende passerar från ett team, system eller en kanal till en annan, eftersom en tappad överlämning är osynlig för alla utom användaren som lämnats att vänta. Designa vad den mottagande sidan ser, vilken kontext som följer med ärendet och vad som händer när överlämningen misslyckas.

Justera teamdesign med tjänstedesign

Förvänta dig att organisationsschemat syns i tjänsten. Det här är Conways lag, iakttagelsen att system kommer att spegla kommunikationsstrukturen hos de organisationer som bygger dem, behandlad på djupet i kapitel 1.2. Om fyra team äger fyra steg i en resa och sällan talar med varandra kommer användaren att känna fyra osammanhängande steg med sprickor emellan. Så tjänstedesign och teamdesign är samma problem sett från två vinklar, och du kan inte rätta en fragmenterad upplevelse enbart med bättre skärmar om det underliggande ägarskapet är fragmenterat. Använd dina tjänstritningar och kundresekartor för att fråga om dina team är dragna kring användarens resa eller kring intern bekvämlighet och var villiga att forma om team, eller att skapa en roll som uttryckligen äger en resa från början till slut, så att någon är ansvarig för helheten och inte bara sin skiva. När du inte kan rita om team, gör åtminstone överlämningarna mellan dem till uttryckliga kontrakt med överenskommen kontext och servicenivåer.

Mät tjänstekvalitet från början till slut

Välj mått som följer användaren från första avsikt till verkligt utfall, inte mått som smickrar en kanal isolerat. Ett webbteam kan nå 98 procent slutförande av formulär medan en tredjedel av de slutförandena misslyckas tyst i en kö i kulisserna, och det lokala måttet kommer aldrig att visa det. Mät slutförande från början till slut (fick personen faktiskt det de kom för), tid från början till slut (hur lång tid från avsikt till utfall, inklusive de osynliga väntetiderna i kulisserna) och ansträngning (hur svårt det var, över alla kanaler de behövde använda). Kombinera driftdata med en direkt läsning av hur det kändes, vare sig genom en transaktionsenkät, en fråga i stil med Net Promoter Score eller löpande forskning. Bevaka särskilt avhoppen från kanal till kanal, eftersom dessa sömmar är där uppmätt kvalitet och upplevd kvalitet divergerar mest. Knyt dessa tjänstemått till produktledningens utfallsuppföljning (kapitel 10.14) så att siffrorna driver prioritering snarare än att sitta på en panel ingen agerar på.

Avvägningar: för- och nackdelar

Tillvägagångssätt	Fördelar	Nackdelar
Tjänsteägarskap från början till slut (ett team äger en resa)	Tydlig ansvarsskyldighet, sammanhängande upplevelse, sömmar blir designade	Skär tvärs genom befintlig organisationsstruktur, svårt att bemanna och finansiera, kan skapa flaskhals
Ägarskap per kanal eller steg	Passar befintliga team, tydlig lokal omfattning, lätt att bemanna	Ingen äger helheten. Luckor mellan kanaler. Lokal optimering
Fullständig tjänstritning i förväg	Blottlägger fel i kulisserna före leverans, gemensam förståelse	Tidskrävande, kan bli föråldrad, risk för analys före handling
Enbart lätt kundresekartläggning	Snabb, billig, tillräcklig för att upptäcka de värsta luckorna	Missar fel i kulisserna och i system som en ritning skulle fånga
Konsekvens över alla kanaler (omnikanal)	Sömlösa överlämningar, kontext följer med över kanaler	Dyr integration, kräver gemensam data och justerade team

Den centrala spänningen är mellan den tjänst användaren behöver, som flödar över era gränser, och den organisation ni faktiskt har, som är dragen längs dem. Lös det proportionellt snarare än dogmatiskt. Ni behöver inte omorganisera hela företaget för att designa en tjänst väl, men ni behöver åtminstone en person eller ett team ansvarigt för utfallet från början till slut, utrustat med en ritning som gör kulisserna synliga och ett mandat att rätta sömmarna. Lägg er tyngsta ritning på resor som har hög volym, höga insatser eller höga felfrekvenser och använd lättare kundresekartor för resten. Målet är inte en perfekt artefakt. Det är en tjänst som fungerar för personen i dess mitt.

Frågor att diskutera med ditt team

Vem äger hela tjänsten från början till slut, från användarens första avsikt till deras verkliga utfall, och vilken makt har de faktiskt? I de flesta stora organisationer är det ärliga svaret “ingen”, eftersom ägarskapet är uppdelat efter kanal och avdelning och varje ägare mäts på sin egen skiva. Den luckan är där tjänster fallerar, eftersom sömmarna mellan ägare tillhör ingen och får ingen uppmärksamhet. Besluta om ni ska skapa en uttrycklig ägare från början till slut, en tjänsteägare eller resans ägare, och var tydliga med om den personen faktiskt kan ändra systemen i kulisserna och teamgränserna eller bara är ansvarig för ett mått de inte kan flytta. Ta med ert nuvarande organisationsschema och er viktigaste resas ritning och lägg dem bredvid varandra för att se vem som rör resan och vem som är ansvarig för den. Om de två inte stämmer har ni hittat källan till era värsta överlämningsfel. Svaret bör ändra hur ni finansierar och bemannar arbetet, inte bara vem som deltar i morgonmötet.
Är våra team dragna kring användarens resa eller kring vår interna bekvämlighet, och är vi villiga att ändra det? Conways lag (kapitel 1.2) betyder att er tjänst kommer att spegla er kommunikationsstruktur vare sig ni vill det eller inte, så en resa uppdelad över fyra okommunikativa team kommer att kännas som fyra osammanhängande steg. Det bekväma draget är att rätta skärmarna och lämna organisationsschemat orört, men det behandlar ett symptom medan orsaken fortsätter regenerera det. Titta ärligt på om era teamgränser skapar just de överlämningsluckor era användare klagar på och väg den verkliga kostnaden för att forma om team mot den löpande kostnaden för en fragmenterad upplevelse. Ta med smärtpunkterna från er kundresekarta och kontrollera hur många som sitter exakt på en teamgräns. Om de flesta gör det kommer ett bättre UI inte att rädda er, och samtalet måste handla om teamdesign. Vad ni beslutar här avgör om era tjänsteförbättringar består eller i tysthet eroderar.
Hur väl betjänar våra verktyg för personalen de människor som använder dem, och hur syns det för kunden? Interna verktyg är den mest pålitligt försummade programvaran i varje stor organisation, eftersom deras användare är fångade och deras budgetar är eftertankar, men en handläggare eller agent som kämpar mot en trasig konsol skickar den friktionen direkt till kunden som förseningar och fel. Fråga när ni senast gjorde forskning på era egna system för personalen, eller om ni antar att verktygen är bra eftersom personalen får betalt för att klara sig. Överväg att kulisserna är där de flesta tysta tjänstefel faktiskt sker, i den manuella ominmatningen och den förlorade kontexten vid överlämningar, inget av vilket måtten på scenen kan se. Ta med en verklig personalmedlem in i rummet och titta på dem slutföra en vanlig uppgift och spåra sedan hur deras kamp når kunden. Om ni aldrig har finansierat interna verktyg som en produkt är detta sannolikt er billigaste stora förbättring av tjänstekvaliteten från början till slut.
Vilket enskilt mått från början till slut skulle tala om för oss om hela tjänsten faktiskt fungerar, och varför följer vi det inte i dag? För ett stort team är den här frågan obekväm eftersom det ärliga svaret vanligen är att varje kanal och avdelning har ett grönt lokalt mått medan ingen mäter om personen fick det de kom för. Slutförandegrad för formulär, samtalshanteringstider och antal avslutade ärenden smickrar alla ägaren som rapporterar dem, och var och en kan förbli frisk medan det sammanhängande utfallet fallerar i en kö i kulisserna. Besluta ett mått på slutförande eller tid från början till slut som följer användaren från första avsikt till verkligt utfall och var tydliga med vem som ska instrumentera det över system som aldrig byggdes för att dela data. Ta med de nuvarande panelerna per kanal, en ritning av en resa med hög volym och en uppskattning av det tysta avhoppet mellan kanaler så att klyftan mellan lokalt grönt och rött från början till slut blir synlig. I företags- och myndighetssammanhang, kom överens om vem som är ansvarig för talet för hela resan och vem som har befogenhet att agera på det, eftersom ett mått ingen enskild ägare kan flytta är ett mått som ändrar ingenting.
Var tvingar vår tjänst användaren att upprepa sig, och vad skulle en version med “berätta en gång” kosta att bygga? Duplicerad datainsamling är den tydligaste signalen på att en tjänst är organiserad kring era interna gränser snarare än användarens behov, och den är dyr åt båda håll: användaren knappar in samma belägg på nytt vid varje överlämning, och varje avdelning betalar för att samla in och verifiera det igen. Den konkurrerande hänsynen är att den gemensamma post som gör “berätta en gång” möjligt kräver integration över system och team som kanske saknar historia av att lita på varandras data, så byggkostnaden och dataförvaltningsarbetet är verkliga. Ta med en kundresekarta annoterad med varje punkt där användaren lämnar information ni redan har och ett grovt antal hur många separata poster som lagrar samma fält. För en myndighetstjänst som spänner över flera förvaltningar, lägg till den rättsliga grunden för att dela den datan mellan dem, eftersom samtycke, integritetslag och regler för informationsstyrning avgör om “berätta en gång” överhuvudtaget är tillåtet innan ni frågar om det är överkomligt.
När kontext lämnas över mellan ett team, ett system eller en kanal, vad följer faktiskt med ärendet, och vad händer när överlämningen misslyckas? Överlämningar är där tjänster i tysthet går sönder, eftersom felet är osynligt för alla utom användaren som lämnats att vänta, och i en stor organisation korsar varje överlämning en gräns där ingen enskild ägare känner ansvar för det som tappas. Besluta medvetet vilken data, historik och status som måste flytta med ett ärende, om den mottagande sidan kan se det och vad återhämtningsvägen är när en överföring stannar av eller anländer ofullständig. Ta med er tjänstritning för en verklig resa och spåra varje linje där ärendet byter händer och markera vilken kontext som bevaras och vad som knappas in på nytt eller går förlorat. I företags- och offentliga tjänster bundna av servicenivåavtal eller lagstadgade svarstider, behandla varje överlämning som ett uttryckligt kontrakt med överenskommen kontext och en definierad reservlösning, eftersom en odokumenterad överlämning är ett avtalsbrott som väntar på att hända som ingen panel kommer att varna er för.

Sektorsperspektiv

Startup. Med en handfull människor och ingen tid för utarbetade artefakter, rita bara upp den enda resa som bär ditt kärnvärde och rita just tillräckligt av den för att se var scenen lämnar över till långsamma eller manuella kulisser. Gör det på en whiteboard en eftermiddag, inte som en studie på sex veckor. Din fördel är att hela tjänsten bor i några få huvuden, så att rätta en trasig överlämning är ett samtal snarare än en förhandling mellan avdelningar. Utnyttja den fördelen innan du växer de gränser som gör överlämningar dyra.

Småföretag. Du har ingen tjänstedesigner och ingen budget för en, så det praktiska draget är att gå din egen resa som kund, notera varje punkt där du får någon att upprepa sig eller vänta på ett manuellt steg och rätta det värsta. Föredra verktyg som redan förenar dina kanaler (en delad inkorg, ett bokningssystem som underrättar personalen) framför att bygga integration du inte kan underhålla. När du köper ett system, väg hur väl det lämnar över kontext till nästa steg, eftersom ett billigt verktyg som tappar kundens uppgifter mellan försäljning och leverans kostar dig mer i förlorad återkommande affär än det sparar.

Storföretag. Kärnproblemet är att en enda resa korsar försäljning, leverans, fakturering och support, var och en med gröna lokala mått och ingen ansvarig för helheten. Investera i fullständiga tjänstritningar för era resor med hög volym och höga insatser, utse en namngiven ägare från början till slut med befogenhet över sömmarna och standardisera ett mått från början till slut som överlever revision och driver prioritering över team. Behandla den gemensamma ärendeposten och konsolerna för personalen som finansierade produkter och gör varje överlämning mellan team till ett uttryckligt kontrakt med överenskommen kontext och servicenivåer.

Offentlig sektor. Tjänster måste organiseras kring medborgarens livshändelse, inte myndighetens struktur, och hållas till publicerade tjänstestandarder med transparens och offentlig ansvarsskyldighet. Upphandlingsregler formar vad du kan bygga, så föredra gemensamma poster och mönster för “berätta en gång” där en rättslig grund för datadelning finns och dokumentera den grunden innan du designar flödet. Forska med verkliga användare, inklusive de mest utsatta, rita upp kulisserna över myndigheter och mät hela resan snarare än varje myndighets skiva, eftersom allmänheten bedömer tjänsten efter om de fick utfallet, inte efter vilken avdelning som lyckades.

Exempel

Startup. En startup på tio personer som sålde en hemförsäkringsprodukt såg sig själv som ett appföretag, och dess app var genuint bra. Men avhoppen var höga och supporten drunknade, så grundarna ritade upp den faktiska skadeanmälningsresan. De fann att den verkliga tjänsten var ögonblicket då en kund hade en sprucken rörledning vid midnatt: appen lämnade över till en e-postkö, som lämnade över till en tredjepartsbedömare kunden inte kunde se, som ringde tillbaka under kontorstid från ett okänt nummer som gick till röstbrevlådan. Den polerade scenen satt ovanpå långsamma, ogenomskinliga kulisser, och “ögonblicket som spelar roll”, en stressande skadeanmälan, var exakt där den fallerade. Att rätta överlämningarna, ge kunden insyn i bedömarsteget och behandla skadearbetsflödet som en del av produkten gjorde mer för retentionen än någon ny appfunktion.

Storföretag. Ett telekomföretag sålde företagsinternet med en tvåminuters onlinebeställning och en tvåveckors leveransmardröm. Försäljning, leverans, fälttekniker och fakturering ägde var sin sträcka av resan och nådde var och en sina egna mål, medan kunden upplevde upprepade förfrågningar om samma information, missade tidsfönster och en första faktura som inte matchade offerten. Tjänstritning över alla fyra avdelningarna blottlade sömmarna: kontext dog vid varje överlämning eftersom ingen gemensam post över beställningen följde kunden genom. Företaget utsåg en ägare för beställning-till-aktivering från början till slut, byggde en gemensam ärendepost som följde med beställningen och kopplade om teamincitament kring det sammanhängande utfallet. De lokala måtten ändrades knappt. Aktiveringstiden från början till slut och klagomålsfrekvensen föll båda kraftigt.

Offentlig sektor. En nationell regering designade om sin tjänst “dödsfall i familjen”, en av de svåraste livshändelser en medborgare möter. Tidigare måste de efterlevande separat underrätta skattemyndigheten, pensionstjänsten, fordonsmyndigheten, passkontoret och kommunen, var och en med eget formulär och var och en krävande samma dödsbevis. Genom att organisera tjänsten kring livshändelsen snarare än kring myndigheterna byggde teamet en enda resa med “berätta en gång” som tog den information en person angav och distribuerade den till varje relevant avdelning bakom synlighetslinjen. I linje med den offentliga sektorns tjänstestandard forskade de med nyligen efterlevande, ritade upp kulisserna över myndigheter och mätte hela resan snarare än varje myndighets del. Slutförandet steg, duplicerade kontakter föll och medborgare behövde inte längre återuppleva en bortgång ett dussin gånger.

Affärsnytta: motiv, ROI och TCO

Avkastningen på tjänstedesign kommer av att stänga luckorna mellan kanaler och team, eftersom det är där värde läcker ut. Fel från början till slut är dyra på sätt som paneler per kanal döljer: en resa som slutförs online men fallerar i kulisserna genererar en supportkontakt, en omgörning och ofta en förlorad kund, och ingen av de kostnaderna landar på den kanal som ser framgångsrik ut. När ni mäter och rättar hela tjänsten minskar ni duplicerad insats (samma data samlad fem gånger), felefterfrågan (kontakter orsakade enbart av att tjänsten sviker första gången) och avhopp från upplevelser som kändes trasiga även när varje del tekniskt fungerade. I företag syns utdelningen som kortare cykler från order till betalning och färre eskaleringar. I myndigheter syns den som lägre kostnad att betjäna och högre lyckat slutförande av tjänster människor inte kan få någon annanstans.

Den totala ägandekostnaden måste väga kostnaden för att göra tjänstedesign mot den långt större kostnaden för den fragmentering ni redan bär. De synliga kostnaderna är forskningen, ritningen, samordningen över team och ibland investeringen i gemensamma system och verktyg för personalen. De dolda kostnaderna för att inte göra det är spridda över supportbudgetar, drift och anseendeskada, vilket är exakt varför ledningen underskattar dem: ingen enskild teambudget visar det fulla priset för en trasig överlämning. För att driva ärendet, sätt ett tal på felefterfrågan och duplicerat arbete i en resa med hög volym, rita upp den och visa ledningen hur mycket av kostnaden som sitter i sömmarna mellan deras befintliga team. Kör sedan en avgränsad pilot på den resan, mät från början till slut före och efter och använd resultatet för att argumentera för de svårare strukturella förändringarna. Att ramma in tjänstedesign som borttagandet av kostnader som redan betalas, bara osynligt, tenderar att flytta ekonomi- och styrningsintressenter mer än någon vädjan till elegans.

Antimönster och fallgropar

Kanalöar. Varje kanal designas och mäts för sig, så att resan ser bra ut överallt och fungerar ingenstans från början till slut.
Läppstift på scenen. Ett polerat UI påskruvat på långsamma eller manuella kulisser, så att upplevelsen går sönder i samma stund användaren behöver att kulisserna svarar.
Organisationsschemat som tjänst. Tjänster strukturerade kring era avdelningar i stället för användarens mål, vilket tvingar användaren att navigera era interna gränser.
Ritningsteater. Utarbetade ritningar ritade en gång, beundrade och aldrig använda för att ändra hur tjänsten faktiskt körs.
Kartläggning bara av den glada vägen. Resor och ritningar som ignorerar fel och återhämtning, vilket är där verkliga tjänster faktiskt gör ont.
Försummade verktyg för personalen. Att behandla interna system för personalen som andra klassens, så att deras friktion läcker rakt igenom till kunden.
Överlämningsamnesi. Kontext som går förlorad vid varje överföring mellan team, system eller kanal, så att användaren förklarar sin situation om och om igen.
Mått som smickrar. Lokala mål per kanal som förblir gröna medan utfallet från början till slut i tysthet fallerar.

Mognadsmodell

Nivå 1, Initiera: Varje kanal och team designas och körs isolerat, reaktivt. Ingen äger tjänsten från början till slut, det finns ingen kundresekarta eller ritning och fel i kulisserna förblir osynliga tills de visar sig som klagomål. Användare upprepar sig rutinmässigt över kanaler eftersom ingen har tittat på helheten.
Nivå 2, Utveckla: Vissa resor är kartlagda och de värsta kanalöverskridande luckorna är kända, men praxisen är fläckig och beror på enskild entusiasm. Kundresekartor finns men når sällan kulisserna, ägarskapet är fortfarande per kanal, verktyg för personalen är en eftertanke och där ritningar görs alls varierar de från team till team.
Nivå 3, Standardisera: Nyckelresor ritas upp från scen till kulisser med driftmedarbetare, med en dokumenterad metod tillämpad konsekvent i hela organisationen. Namngivna tjänsteägare är ansvariga från början till slut, överlämningar är uttryckliga kontrakt med överenskommen kontext, verktyg för personalen designas medvetet och ansatsen upprätthålls snarare än är valfri.
Nivå 4, Hantera: Tjänsten mäts och styrs med data. Slutförande från början till slut, tid från början till slut (inklusive osynliga väntetider i kulisserna), användarens ansträngning, felefterfrågan och avhopp från kanal till kanal följs mot utgångslägen, och överlämningsfel och duplicerad datainsamling kvantifieras snarare än antas. Ritningar hålls aktuella, tjänsteägare hålls till mål från början till slut och beslut att gå eller inte gå på ändringar vilar på belägg i stället för lokala kanalmått.
Nivå 5, Orkestrera: Teamdesign och tjänstedesign är justerade så att ägarskapet följer resan, och organisationen är strukturerad kring användarmål och livshändelser snarare än avdelningar. Mått från början till slut driver prioritering, organisationen ritar kontinuerligt upp, mäter och formar om både upplevelse och drift tillsammans och den anpassar hela tjänsten när användarbehov, kanaler och gränser mellan team skiftar.

Idéer för diskussion

När en resa korsar flera team, är det bättre att utse en ägare från början till slut eller rita om teamen kring resan, och vad avgör valet?
Hur mycket av er tjänstekvalitet kan rättas med bättre design på scenen, och hur mycket kräver att kulisserna eller organisationsschemat ändras?
Var i er tjänst måste användare oftast upprepa sig, och vad skulle en version med “berätta en gång” kosta att bygga?
Hur finansierar och prioriterar ni verktyg för personalen när deras användare är fångade och inte kan rösta med fötterna?
Bör tjänster organiseras kring livshändelser eller användarmål även när det går rakt emot era finansierings- och rapporteringslinjer?
Vilket enskilt mått från början till slut skulle bäst tala om för er om hela tjänsten fungerar, och varför följer ni det inte i dag?

Viktigaste punkter

Designa hela tjänsten över kanaler och över tid, inte en skärm, och kom ihåg att användaren inte bryr sig om var dina teamgränser går.
Scen och kulisser är ett system. En bra upplevelse är bara så bra som verksamheten bakom den kan bära.
Tjänstritningen är din kärnartefakt: den länkar kontaktpunkter på scenen till de människor, system och överlämningar i kulisserna som levererar dem.
Organisationsschemat syns i tjänsten (Conways lag), så tjänstedesign och teamdesign måste röra sig tillsammans.
Behandla verktyg för personalen och överlämningarna mellan team som förstklassiga delar av tjänsten, eftersom deras friktion når kunden.
Mät tjänsten från början till slut, från första avsikt till verkligt utfall, och organisera kring användarens mål eller livshändelse snarare än dina avdelningar.

Referenser och vidare 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