5.9 Servicedesign

Overzicht en motivatie

Servicedesign is de praktijk van het vormgeven van de hele dienst die iemand ervaart, over elk kanaal en over de volle tijdspanne, in plaats van één scherm of app. Wanneer iemand een paspoort verlengt, een bankrekening opent of een kapotte straatlantaarn meldt, ervaart die persoon je product niet. Die persoon ervaart een dienst: een telefoontje, een website, een brief in de post, een wachtrij, een e-mail die nooit aankomt, een dossierbehandelaar die hun gegevens opnieuw moet intikken in een systeem dat niet kan zien wat de website al weet. Hoofdstuk 5.1 behandelt het vak van individuele interfaces ontwerpen. Servicedesign zoomt uit naar de hele reis en naar alles achter de balie dat de voorkant van de balie laat werken.

Dat onderscheid “achter de balie” is de kern. Servicedesign verdeelt de wereld in de front-stage, alles wat de gebruiker ziet en aanraakt, en de back-stage, de mensen, systemen en processen die de dienst leveren maar onzichtbaar blijven voor de gebruiker. Goede front-stage-ervaringen falen voortdurend omdat de back-stage ze niet kan dragen. Een gelikt boekingsformulier dat in een spreadsheet belandt die een medewerker twee keer per dag controleert is een snelle front-stage vastgeschroefd aan een trage back-stage, en de gebruiker voelt de mismatch als een stilte van drie dagen. De hele dienst ontwerpen betekent beide helften samen ontwerpen, en de naden ertussen.

Voor grote teams is dit onvermijdelijk een organisatieprobleem. Diensten omspannen bijna altijd meerdere teams, afdelingen en systemen, en de grenzen tussen die eigenaren zijn precies waar de ervaring van de gebruiker uiteenvalt. In ondernemingsomgevingen kan één klantreis verkoop, provisioning, facturering en support kruisen, elk met eigen tools en doelen en geen verantwoordelijk voor het geheel. Bij de overheid is de inzet nog hoger: iemand die voor een levensgebeurtenis staat zoals een overlijden of een baby moet door een dozijn aparte instanties navigeren, die elk hetzelfde bewijs vragen, omdat de diensten zijn georganiseerd rond de structuur van de overheid in plaats van de behoefte van de persoon. Servicedesign is hoe je het geheel laat samenhangen voor de mens in het midden.

Kernprincipes

Ontwerp de hele dienst over kanalen en tijd, niet één scherm. De gebruiker geeft niet om waar je teamgrenzen liggen.
Front-stage en back-stage zijn één systeem. Een ervaring is maar zo goed als de operaties erachter kunnen dragen.
Het organigram verschijnt in de dienst. Als teams gesiloëerd zijn, voelt de dienst gesiloëerd, dus teamontwerp en servicedesign moeten samen bewegen.
De overdrachten tussen kanalen en teams zijn waar diensten breken. Ontwerp de naden net zo bewust als de stappen.
Tools voor medewerkers zijn onderdeel van de dienst. Een gefrustreerde medewerker met een slechte console produceert een gefrustreerde klant.
Meet de dienst van begin tot eind, van de eerste intentie van de gebruiker tot hun echte uitkomst, niet de lokale statistiek van één kanaal.
Organiseer rond het doel of de levensgebeurtenis van de gebruiker, niet rond je interne afdelingen.

Aanbevelingen

Breng de klantreis in kaart over elk kanaal

Begin met de werkelijke reis in kaart te brengen die een persoon aflegt om tot een uitkomst te komen, als onderdeel van de bredere klantervaring. Een klantreiskaart legt de fasen uit waar de gebruiker doorheen beweegt, van eerst beseffen dat er een behoefte is tot het bereiken van het doel en daarna, en legt bij elke fase vast wat ze proberen te doen, wat ze denken en voelen en in welk kanaal ze zitten. De waarde komt uit het omspannen van kanalen: de meeste echte reizen springen tussen een website, een telefoonlijn, een e-mail, een app en een fysieke locatie, en de ergste pijn zit in de gaten tussen die kanalen, waar context verloren gaat en de gebruiker opnieuw moet beginnen. Veranker de kaart in onderzoek (hoofdstuk 5.8) in plaats van je aannames, want de reis die je je voorstelt en de reis die mensen werkelijk afleggen zijn zelden dezelfde. Markeer de “momenten die tellen”, de paar punten waar de ervaring beslissend slaagt of faalt, en concentreer je inspanning daar in plaats van haar gelijk te verdelen. Een reis die op elk afzonderlijk kanaal soepel lijkt kan van begin tot eind toch ellendig zijn, en alleen de kanaaloverstijgende blik onthult het.

Bouw een servicegrondplan dat front-stage met back-stage verbindt

Het kernartefact van deze discipline is het servicegrondplan. Waar een klantreiskaart de blik van de gebruiker neemt, voegt een grondplan de lagen eronder toe. Een typisch grondplan loopt in horizontale banen: de acties van de klant bovenaan, dan de front-stage-contactpunten waarmee ze interacteren, dan een “zichtbaarheidslijn” waaronder de back-stage-acties van medewerkers zitten, en ten slotte de ondersteunende systemen en processen die alles erboven mogelijk maken. Lees een kolom van boven naar beneden en je ziet precies wat achter de schermen moet gebeuren om één front-stage-moment te laten werken, en waar het zal breken als een systeem traag is of een overdracht vaag. Grondplannen zijn waar je de stille falen vindt: het handmatig overtypen, de nachtelijke batchjob, het team dat niet weet dat het een afhankelijkheid is. Teken ze met de operationele medewerkers die de back-stage werkelijk draaien, niet alleen met ontwerpers, want die medewerkers weten waar het echte werk gebeurt. Een grondplan dat alleen het gelukkige pad toont is decoratie. Teken ook de fout- en herstelpaden.

Ontwerp de back-stage en tools voor medewerkers als eersterangs

Behandel de tools die je medewerkers gebruiken als onderdeel van het product, want voor de klant zijn ze dat. Wanneer een callcentermedewerker, dossierbehandelaar of magazijnmedewerker vecht met een trage, lelijke, half-kapotte interne console, wordt die wrijving direct doorgegeven aan de persoon die ze bedienen, als langere wachttijden, verkeerde antwoorden en zichtbare frustratie. Interne tools zijn chronisch ondergefinancierd juist omdat hun gebruikers gebonden zijn en niet kunnen weglopen, en daarom waarschuwt hoofdstuk 5.1 dat software voor gebonden gebruikers wordt betaald in fouten en verloren productiviteit in plaats van verloop. Geef systemen voor medewerkers dezelfde onderzoeks-, ontwerp- en kwaliteitslat als klantgerichte systemen. Besteed bijzondere aandacht aan de overdrachten, de momenten waarop een zaak van het ene team, systeem of kanaal naar het andere gaat, want een gemiste overdracht is voor niemand zichtbaar behalve de gebruiker die wacht. Ontwerp wat de ontvangende kant ziet, welke context met de zaak meereist en wat er gebeurt als de overdracht faalt.

Stem teamontwerp af op servicedesign

Verwacht dat het organigram in de dienst verschijnt. Dit is de wet van Conway, de observatie dat systemen de communicatiestructuren gaan spiegelen van de organisaties die ze bouwen, diepgaand behandeld in hoofdstuk 1.2. Als vier teams vier stappen van een reis bezitten en zelden praten, voelt de gebruiker vier losse stappen met scheuren ertussen. Servicedesign en teamontwerp zijn dus hetzelfde probleem vanuit twee hoeken bekeken, en je kunt een gefragmenteerde ervaring niet louter met betere schermen herstellen als het onderliggende eigenaarschap gefragmenteerd is. Gebruik je servicegrondplannen en klantreiskaarten om te vragen of je teams rond de reis van de gebruiker zijn getekend of rond interne gemakzucht, en wees bereid teams opnieuw vorm te geven, of een rol te creëren die expliciet een reis van begin tot eind bezit, zodat iemand verantwoordelijk is voor het geheel en niet alleen hun stuk. Wanneer je teams niet opnieuw kunt tekenen, maak dan ten minste de overdrachten ertussen expliciete contracten met afgesproken context en servicelevels.

Meet servicekwaliteit van begin tot eind

Kies statistieken die de gebruiker volgen van eerste intentie tot echte uitkomst, niet statistieken die één kanaal in isolatie vleien. Een websiteteam kan een voltooiingspercentage van formulieren van 98 procent halen terwijl een derde van die voltooiingen stilletjes faalt in een back-stage-wachtrij, en de lokale statistiek zal het nooit tonen. Meet voltooiing van begin tot eind (kreeg de persoon werkelijk wat ze kwamen halen), doorlooptijd van begin tot eind (hoe lang van intentie tot uitkomst, inclusief de onzichtbare back-stage-wachttijden) en inspanning (hoe moeilijk het was, over alle kanalen die ze moesten gebruiken). Combineer operationele data met een directe lezing van hoe het voelde, via een transactionele enquête, een vraag in de stijl van Net Promoter Score of doorlopend onderzoek. Let vooral op de afhaakpunten van kanaal naar kanaal, want die naden zijn waar gemeten kwaliteit en gevoelde kwaliteit het meest uiteenlopen. Verbind deze servicestatistieken met het uitkomsten volgen van productmanagement (hoofdstuk 10.14) zodat de getallen prioritering drijven in plaats van op een dashboard te liggen waar niemand naar handelt.

Afwegingen: voor- en nadelen

Aanpak	Voordelen	Nadelen
Eigenaarschap van de dienst van begin tot eind (één team bezit een reis)	Heldere verantwoording, samenhangende ervaring, naden worden ontworpen	Snijdt door bestaande organisatiestructuur, moeilijk te bemannen en te financieren, kan knelpunt worden
Eigenaarschap per kanaal of per stap	Past bij bestaande teams, heldere lokale scope, makkelijk te bemannen	Niemand bezit het geheel. Gaten tussen kanalen. Lokale optimalisatie
Volledig servicegrondplan vooraf	Brengt back-stage-falen aan het licht vóór oplevering, gedeeld begrip	Tijdrovend, kan verouderen, riskeert analyse vóór actie
Alleen lichtgewicht klantreiskaarten	Snel, goedkoop, goed genoeg om de ergste gaten te zien	Mist back-stage- en systeemfalen die een grondplan zou vangen
Omnichannel-consistentie (verenigd over kanalen)	Naadloze overdrachten, context reist mee over kanalen	Dure integratie, vraagt gedeelde data en uitgelijnde teams

De centrale spanning is tussen de dienst die de gebruiker nodig heeft, die over je grenzen stroomt, en de organisatie die je werkelijk hebt, die langs die grenzen is getekend. Los het evenredig op in plaats van dogmatisch. Je hoeft niet het hele bedrijf te reorganiseren om één dienst goed te ontwerpen, maar je hebt wel minstens één persoon of team nodig dat verantwoordelijk is voor de uitkomst van begin tot eind, gewapend met een grondplan dat de back-stage zichtbaar maakt en een mandaat om de naden te repareren. Besteed je zwaarste grondplannen aan de reizen met hoog volume, hoge inzet of veel falen, en gebruik lichtere klantreiskaarten voor de rest. Het doel is geen perfect artefact. Het is een dienst die werkt voor de persoon in het midden.

Vragen om met je team te bespreken

Wie bezit de hele dienst van begin tot eind, van de eerste intentie van de gebruiker tot hun echte uitkomst, en welke macht hebben ze werkelijk? In de meeste grote organisaties is het eerlijke antwoord “niemand”, omdat eigenaarschap is verdeeld per kanaal en per afdeling en elke eigenaar wordt afgerekend op zijn eigen stuk. Dat gat is waar diensten falen, aangezien de naden tussen eigenaren aan niemand toebehoren en geen aandacht krijgen. Besluit of je een expliciete eigenaar van begin tot eind maakt, een service-eigenaar of reiseigenaar, en wees duidelijk of die persoon de back-stage-systemen en teamgrenzen werkelijk kan veranderen of slechts verantwoordelijk is voor een statistiek die hij niet kan bewegen. Neem je huidige organigram en het grondplan van je belangrijkste reis mee en leg ze naast elkaar om te zien wie de reis raakt en wie ervoor verantwoordelijk is. Als de twee niet overeenkomen, heb je de bron van je ergste overdrachtsfalen gevonden. Het antwoord moet veranderen hoe je het werk financiert en bemant, niet alleen wie bij de stand-up aanwezig is.
Zijn onze teams rond de reis van de gebruiker getekend of rond onze interne gemakzucht, en zijn we bereid dat te veranderen? De wet van Conway (hoofdstuk 1.2) betekent dat je dienst je communicatiestructuur zal spiegelen of je dat nu bedoelt of niet, dus een reis verdeeld over vier niet-communicerende teams voelt als vier losse stappen. De comfortabele zet is de schermen repareren en het organigram laten, maar dat behandelt een symptoom terwijl de oorzaak het blijft regenereren. Kijk eerlijk of je teamgrenzen precies de overdrachtsgaten creëren waarover je gebruikers klagen, en weeg de echte kosten van teams hervormen af tegen de doorlopende kosten van een gefragmenteerde ervaring. Neem de pijnpunten van je klantreiskaart mee en controleer hoeveel ervan precies op een teamgrens zitten. Als de meeste dat doen, redt betere UI je niet, en moet het gesprek over teamontwerp gaan. Wat je hier besluit bepaalt of je serviceverbeteringen beklijven of stilletjes eroderen.
Hoe goed bedienen onze tools voor medewerkers de mensen die ze gebruiken, en hoe toont dat zich voor de klant? Interne tools zijn de meest betrouwbaar verwaarloosde software in elke grote organisatie, omdat hun gebruikers gebonden zijn en hun budgetten bijzaak, toch geeft een dossierbehandelaar of medewerker die vecht met een kapotte console die wrijving direct door aan de klant als vertragingen en fouten. Vraag wanneer je voor het laatst onderzoek deed naar je eigen systemen voor medewerkers, of dat je aanneemt dat omdat medewerkers worden betaald om ermee om te gaan, de tools prima zijn. Bedenk dat de back-stage waar de meeste stille servicefalen werkelijk gebeuren, in het handmatig overtypen en de verloren context bij overdrachten, die de front-stage-statistieken niet kunnen zien. Neem een echte medewerker mee de kamer in en kijk hoe die een gangbare taak afrondt, en traceer dan hoe hun strijd de klant bereikt. Als je interne tools nooit als product hebt gefinancierd, is dit waarschijnlijk je goedkoopste grote verbetering van servicekwaliteit van begin tot eind.
Welke enkele statistiek van begin tot eind zou ons vertellen of de hele dienst werkelijk werkt, en waarom volgen we haar vandaag niet? Voor een groot team is deze vraag ongemakkelijk omdat het eerlijke antwoord meestal is dat elk kanaal en elke afdeling een groene lokale statistiek heeft terwijl niemand meet of de persoon kreeg wat hij kwam halen. Voltooiingspercentages van formulieren, afhandeltijden van gesprekken en aantallen gesloten tickets vleien allemaal de eigenaar die ze rapporteert, en elk kan gezond blijven terwijl de samengestelde uitkomst faalt in een back-stage-wachtrij. Besluit een voltooiings- of doorlooptijdmaat van begin tot eind die de gebruiker volgt van eerste intentie tot echte uitkomst, en wees duidelijk wie haar zal instrumenteren over systemen die nooit zijn gebouwd om data te delen. Neem de huidige dashboards per kanaal mee, een grondplan van één reis met hoog volume en een schatting van het stille afhaken tussen kanalen zodat het gat tussen lokaal groen en rood van begin tot eind zichtbaar wordt. Spreek in omgevingen van onderneming en overheid af wie verantwoordelijk is voor het getal van de hele reis en wie de bevoegdheid heeft ernaar te handelen, want een statistiek die geen enkele eigenaar kan bewegen is een statistiek die niets verandert.
Waar dwingt onze dienst de gebruiker zichzelf te herhalen, en wat zou een “vertel het ons eenmaal”-versie kosten om te bouwen? Dubbele gegevensverzameling is het duidelijkste signaal dat een dienst rond je interne grenzen is georganiseerd in plaats van de behoefte van de gebruiker, en het is duur aan beide kanten: de gebruiker voert hetzelfde bewijs bij elke overdracht opnieuw in, en elke afdeling betaalt om het opnieuw te verzamelen en te verifiëren. De concurrerende overweging is dat het gedeelde dossier dat “vertel het ons eenmaal” mogelijk maakt integratie vraagt over systemen en teams die mogelijk geen geschiedenis hebben van elkaars data vertrouwen, dus de bouwkosten en het datagovernancewerk zijn echt. Neem een klantreiskaart mee geannoteerd met elk punt waar de gebruiker informatie aanlevert die je al hebt, en een grove telling van hoeveel aparte dossiers hetzelfde veld opslaan. Voeg voor een overheidsdienst die meerdere instanties omspant de rechtsgrond toe voor het delen van die data tussen hen, aangezien toestemming, privacywet en informatiegovernanceregels beslissen of “vertel het ons eenmaal” überhaupt is toegestaan voordat je vraagt of het betaalbaar is.
Wanneer context wordt overgedragen tussen een team, systeem of kanaal, wat reist er werkelijk met de zaak mee, en wat gebeurt er als de overdracht faalt? Overdrachten zijn waar diensten stilletjes breken, omdat het falen voor niemand zichtbaar is behalve de gebruiker die wacht, en in een grote organisatie elke overdracht een grens kruist waar geen enkele eigenaar zich verantwoordelijk voelt voor wat wordt laten vallen. Besluit bewust welke data, geschiedenis en status met een zaak mee moeten gaan, of de ontvangende kant ze kan zien en wat het herstelpad is wanneer een overdracht stokt of onvolledig aankomt. Neem je servicegrondplan voor een echte reis mee en traceer elke lijn waar de zaak van hand wisselt, markerend welke context behouden blijft en wat opnieuw wordt ingetikt of verloren gaat. Behandel in diensten van onderneming en publieke sector gebonden aan service-level agreements of wettelijke responstijden elke overdracht als expliciet contract met afgesproken context en een gedefinieerde terugvaloptie, want een ongedocumenteerde overdracht is een schending die wacht te gebeuren en die geen enkel dashboard je zal melden.

Sectorperspectief

Startup. Met een handvol mensen en geen tijd voor uitgebreide artefacten teken je alleen de ene reis uit die je kernwaarde draagt, en teken je net genoeg om te zien waar de front-stage overdraagt aan een trage of handmatige back-stage. Doe het op een whiteboard in een middag, niet als studie van zes weken. Je voordeel is dat de hele dienst in een paar hoofden leeft, dus een kapotte overdracht repareren is een gesprek in plaats van een onderhandeling tussen afdelingen. Besteed dat voordeel voordat je de grenzen laat groeien die overdrachten duur maken.

Kleinbedrijf. Je hebt geen servicedesigner en geen budget voor er een, dus de praktische zet is je eigen reis als klant te lopen, elk punt te noteren waar je iemand zichzelf laat herhalen of op een handmatige stap laat wachten en het ergste te repareren. Geef de voorkeur aan tools die je kanalen al verbinden (een gedeelde inbox, een boekingssysteem dat medewerkers meldt) boven integratie bouwen die je niet kunt onderhouden. Weeg bij het kopen van een systeem hoe goed het context aan de volgende stap geeft, want een goedkope tool die de gegevens van de klant laat vallen tussen verkoop en uitvoering kost je meer aan verloren herhaalbusiness dan hij bespaart.

Grote onderneming. Het kernprobleem is dat één reis verkoop, provisioning, facturering en support kruist, elk met groene lokale statistieken en geen verantwoordelijk voor het geheel. Investeer in volledige servicegrondplannen voor je reizen met hoog volume en hoge inzet, benoem een eigenaar van begin tot eind met gezag over de naden en standaardiseer een statistiek van begin tot eind die een audit overleeft en prioritering over teams drijft. Behandel het gedeelde dossier en de consoles voor medewerkers als gefinancierde producten en maak elke overdracht tussen teams een expliciet contract met afgesproken context en servicelevels.

Overheid. Diensten moeten rond de levensgebeurtenis van de burger zijn georganiseerd, niet de structuur van de instantie, en gehouden aan gepubliceerde dienststandaarden met transparantie en publieke verantwoording. Aanbestedingsregels bepalen wat je kunt bouwen, dus geef de voorkeur aan gedeelde dossiers en “vertel het ons eenmaal”-patronen waar de rechtsgrond voor het delen van data bestaat, en documenteer die grond voordat je de stroom ontwerpt. Doe onderzoek met echte gebruikers, ook de meest kwetsbaren, teken de back-stage over instanties heen en meet de hele reis in plaats van het stuk van elke instantie, want het publiek beoordeelt de dienst op of het de uitkomst kreeg, niet op welke afdeling slaagde.

Voorbeelden

Startup. Een startup van tien personen die een woonverzekering verkocht zag zichzelf als appbedrijf, en haar app was werkelijk goed. Maar het verloop was hoog en support verdronk, dus tekenden de oprichters het werkelijke schadeafhandelingstraject uit. Ze vonden dat de echte dienst het moment was waarop een klant om middernacht een gesprongen waterleiding had: de app droeg over aan een e-mailwachtrij, die overdroeg aan een externe schade-expert die de klant niet kon zien en die tijdens kantooruren terugbelde vanaf een onbekend nummer dat in de voicemail belandde. De gepolijste front-stage zat bovenop een trage, ondoorzichtige back-stage, en het “moment dat telt”, een stressvolle schademelding, was precies waar het faalde. De overdrachten repareren, de klant inzicht geven in de stap van de expert en de schadeworkflow als onderdeel van het product behandelen deed meer voor retentie dan enige nieuwe appfunctie.

Grote onderneming. Een telecombedrijf verkocht zakelijk internet met een online bestelling van twee minuten en een leveringsnachtmerrie van twee weken. Verkoop, provisioning, veldengineering en facturering bezaten elk een stuk van de reis en haalden elk hun eigen doelen, terwijl de klant herhaalde verzoeken om dezelfde informatie ervoer, gemiste afspraakvensters en een eerste factuur die niet met de offerte overeenkwam. Servicegrondplannen over alle vier de afdelingen onthulden de naden: context stierf bij elke overdracht omdat geen gedeeld dossier van de bestelling de klant volgde. Het bedrijf benoemde een eigenaar van bestelling tot activering van begin tot eind, bouwde een gedeeld dossier dat met de bestelling meereisde en herbedraadde de teamprikkels rond de samengestelde uitkomst. Lokale statistieken veranderden nauwelijks. De activeringstijd van begin tot eind en het klachtenpercentage daalden allebei sterk.

Overheid. Een nationale overheid herontwierp haar dienst “overlijden van een familielid”, een van de moeilijkste levensgebeurtenissen die een burger tegenkomt. Eerder moesten nabestaanden de belastingdienst, de pensioendienst, de voertuigdienst, de paspoortbalie en de lokale overheid afzonderlijk melden, elk met een eigen formulier en elk eisend dezelfde overlijdensakte. De dienst organiseren rond de levensgebeurtenis in plaats van rond de instanties, bouwde het team één “vertel het ons eenmaal”-reis die de informatie die iemand invoerde nam en achter de zichtbaarheidslijn aan elke relevante afdeling verspreidde. Aansluitend op de dienststandaard van de publieke sector deed men onderzoek met recent nabestaanden, tekende de back-stage over instanties heen en mat de hele reis in plaats van het deel van elke instantie. Voltooiing steeg, dubbel contact daalde en burgers hoefden een overlijden niet meer een dozijn keer opnieuw te beleven.

Zakelijke onderbouwing: motivatie, ROI en TCO

Het rendement van servicedesign komt uit het dichten van de gaten tussen kanalen en teams, want daar lekt waarde weg. Falen van begin tot eind is duur op manieren die dashboards per kanaal verbergen: een reis die online voltooit maar in de back-stage faalt genereert een supportcontact, een herdoen en vaak een verloren klant, en geen van die kosten landt bij het kanaal dat succesvol lijkt. Wanneer je de hele dienst meet en repareert, verminder je dubbele inspanning (dezelfde data vijf keer verzameld), faalvraag (contacten veroorzaakt puur doordat de dienst de eerste keer faalde) en verloop door ervaringen die kapot voelden ook als elk deel technisch werkte. Bij ondernemingen toont de opbrengst zich als kortere order-to-cash-cycli en minder escalaties. Bij de overheid toont ze zich als lagere kosten per dienst en hogere succesvolle voltooiing van diensten die mensen nergens anders kunnen krijgen.

De total cost of ownership moet de kosten van servicedesign afwegen tegen de veel grotere kosten van de fragmentatie die je al draagt. De zichtbare kosten zijn het onderzoek, het grondplan tekenen, de coördinatie over teams en soms de investering in gedeelde systemen en tools voor medewerkers. De verborgen kosten van het niet doen zijn verspreid over supportbudgetten, operaties en reputatieschade, wat precies is waarom leiderschap ze onderschat: geen enkel budget van een team toont de volle prijs van een kapotte overdracht. Zet om de zaak te maken een getal op faalvraag en dubbel werk in één reis met hoog volume, teken haar uit en toon het bestuur hoeveel van de kosten in de naden tussen hun bestaande teams zit. Draai dan een begrensde pilot op die reis, meet van begin tot eind voor en na en gebruik het resultaat om te pleiten voor de moeilijkere structurele veranderingen. Servicedesign formuleren als het wegnemen van kosten die al worden betaald, alleen onzichtbaar, beweegt financiële en governancebelanghebbenden doorgaans meer dan enig beroep op elegantie.

Antipatronen en valkuilen

Kanaaleilanden. Elk kanaal wordt apart ontworpen en gemeten, zodat de reis overal prima lijkt en van begin tot eind nergens werkt.
Front-stage-lipstick. Een gepolijste UI vastgeschroefd aan een trage of handmatige back-stage, zodat de ervaring breekt zodra de gebruiker de back-stage nodig heeft om te reageren.
Organigram als dienst. Diensten gestructureerd rond je afdelingen in plaats van het doel van de gebruiker, wat de gebruiker dwingt door je interne grenzen te navigeren.
Grondplantheater. Uitgebreide grondplannen eenmaal getekend, bewonderd en nooit gebruikt om te veranderen hoe de dienst werkelijk draait.
Alleen het gelukkige pad in kaart brengen. Reizen en grondplannen die falen en herstel negeren, waar echte diensten werkelijk pijn doen.
Verwaarloosde medewerkerstools. Interne systemen voor medewerkers als tweederangs behandelen, zodat hun wrijving direct doorlekt naar de klant.
Overdrachtsamnesie. Context verloren bij elke overdracht tussen team, systeem of kanaal, zodat de gebruiker zijn situatie steeds opnieuw uitlegt.
Statistieken die vleien. Lokale doelen per kanaal die groen blijven terwijl de uitkomst van begin tot eind stilletjes faalt.

Volwassenheidsmodel

Niveau 1, Initiëren: Elk kanaal en team wordt in isolatie ontworpen en gerund, reactief. Niemand bezit de dienst van begin tot eind, er is geen klantreiskaart of grondplan en back-stage-falen blijft onzichtbaar tot het als klacht boven komt. Gebruikers herhalen zich routinematig over kanalen omdat niemand naar het geheel heeft gekeken.
Niveau 2, Ontwikkelen: Sommige reizen zijn in kaart gebracht en de ergste gaten tussen kanalen zijn bekend, maar de praktijk is onregelmatig en hangt af van individueel enthousiasme. Klantreiskaarten bestaan maar bereiken zelden de back-stage, eigenaarschap is nog per kanaal, tools voor medewerkers zijn een bijgedachte en waar grondplannen gebeuren verschilt het van team tot team.
Niveau 3, Standaardiseren: Belangrijke reizen zijn van front-stage tot back-stage uitgetekend met operationele medewerkers, met een gedocumenteerde methode consistent toegepast over de organisatie. Benoemde service-eigenaren zijn van begin tot eind verantwoordelijk, overdrachten zijn expliciete contracten met afgesproken context, medewerkerstools worden bewust ontworpen en de aanpak wordt afgedwongen in plaats van optioneel.
Niveau 4, Beheersen: De dienst wordt gemeten en beheerst met data. Voltooiing van begin tot eind, doorlooptijd van begin tot eind (inclusief onzichtbare back-stage-wachttijden), inspanning van de gebruiker, faalvraag en afhaken van kanaal naar kanaal worden gevolgd tegen uitgangswaarden, en overdrachtsfalen en dubbele gegevensverzameling worden gekwantificeerd in plaats van aangenomen. Grondplannen worden actueel gehouden, service-eigenaren worden aan doelen van begin tot eind gehouden en go/no-go-beslissingen over wijzigingen rusten op dat bewijs in plaats van op lokale kanaalstatistieken.
Niveau 5, Orkestreren: Teamontwerp en servicedesign zijn uitgelijnd zodat eigenaarschap de reis volgt, en de organisatie is gestructureerd rond doelen en levensgebeurtenissen van gebruikers in plaats van afdelingen. Statistieken van begin tot eind drijven prioritering, de organisatie tekent, meet en hervormt voortdurend ervaring en operaties samen, en past de hele dienst aan naarmate behoeften van gebruikers, kanalen en grenzen tussen teams verschuiven.

Ideeën voor discussie

Wanneer een reis meerdere teams kruist, is het beter één eigenaar van begin tot eind te benoemen of de teams rond de reis opnieuw te tekenen, en wat bepaalt de keuze?
Hoeveel van je servicekwaliteit kan worden opgelost met beter front-stage-ontwerp, en hoeveel vraagt het veranderen van de back-stage of het organigram?
Waar in je dienst moeten gebruikers zichzelf het vaakst herhalen, en wat zou een “vertel het ons eenmaal”-versie kosten om te bouwen?
Hoe financier en prioriteer je tools voor medewerkers wanneer hun gebruikers gebonden zijn en niet met hun voeten kunnen stemmen?
Moeten diensten rond levensgebeurtenissen of doelen van gebruikers worden georganiseerd, ook als dat recht ingaat tegen je financierings- en rapportagelijnen?
Welke enkele statistiek van begin tot eind zou je het best vertellen of je hele dienst werkt, en waarom volg je haar vandaag niet?

Belangrijkste inzichten

Ontwerp de hele dienst over kanalen en in de tijd, niet één scherm, en onthoud dat de gebruiker er niet om geeft waar je teamgrenzen vallen.
Front-stage en back-stage zijn één systeem. Een geweldige ervaring is maar zo goed als de operaties erachter kunnen dragen.
Het servicegrondplan is je kernartefact: het verbindt front-stage-contactpunten met de back-stage-mensen, -systemen en -overdrachten die ze leveren.
Het organigram verschijnt in de dienst (wet van Conway), dus servicedesign en teamontwerp moeten samen bewegen.
Behandel tools voor medewerkers en de overdrachten tussen teams als eersterangs onderdelen van de dienst, omdat hun wrijving de klant bereikt.
Meet de dienst van begin tot eind, van eerste intentie tot echte uitkomst, en organiseer rond het doel of de levensgebeurtenis van de gebruiker in plaats van je afdelingen.

Referenties en verder lezen

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