Je hebt genoeg klantinzichten, maar veranderen ze ook je roadmap?

Een servicemedewerker ziet voor de derde keer dezelfde klacht binnenkomen. Een klant loopt vast tijdens het bestellen en neemt contact op omdat de informatie op de website onduidelijk is. Het probleem wordt netjes geregistreerd in de servicetool. Maar hoe zorg je ervoor dat er meer gebeurt met dit klantsignaal?

Een paar dagen later ziet een UX-onderzoeker tijdens een gebruikerstest dat iemand op precies hetzelfde punt twijfelt. In webanalytics valt bovendien op dat relatief veel bezoekers daar afhaken. De CRO-specialist zet het onderwerp op een lijst met mogelijke experimenten. Ondertussen werkt het productteam verder aan de bestaande roadmap.

Iedereen ziet een deel van hetzelfde probleem, toch verandert er weinig. De klacht blijft in de servicetool staan, het onderzoeksresultaat komt in een presentatie en het experimentidee belandt op een backlog. Tegen de tijd dat de verschillende signalen bij elkaar komen, is de volgende sprint alweer gepland.

Ik kom dit patroon vaak tegen. Het probleem zit zelden in een gebrek aan klantkennis. Het zit in de manier waarop informatie, werk en verantwoordelijkheid door de organisatie bewegen.

In eerdere artikelen schreef ik al over experimenten die in rapporten verdwijnen en over de klantreis als verbindend systeem tussen teams. Daarmee ontstaat een volgende vraag: hoe zorg je ervoor dat een klantsignaal daadwerkelijk een besluit kan veranderen?

Een interessant antwoord komt uit een vakgebied dat jaren geleden al tegen een vergelijkbaar probleem aanliep: DevOps.

Wat DevOps veranderde

Voor de opkomst van DevOps waren softwareontwikkeling en IT-beheer vaak gescheiden werelden. Development bouwde nieuwe functionaliteiten en droeg die daarna over aan Operations. Het ene team werd beloond voor snelheid en verandering, het andere voor stabiliteit en voorspelbaarheid.

Als er na de overdracht iets misging, kwam feedback terug. Vaak laat, via meerdere mensen en wanneer de schade al was ontstaan. Beide teams konden hun eigen werk goed uitvoeren, terwijl het totale proces traag en kwetsbaar bleef.

DevOps veranderde daarom vooral de verbinding tussen die werkzaamheden. De afstand tussen bouwen, gebruiken, meten en herstellen werd kleiner. Ontwikkelaars kregen sneller zicht op wat er in de praktijk gebeurde. Operations werd eerder betrokken bij veranderingen. Kennis en verantwoordelijkheid bewogen mee met het werk.

Daar zie ik de belangrijkste les voor Experienceteams. UX, onderzoek, CRO, customer service, marketing en product hebben allemaal invloed op dezelfde klantervaring, maar zijn meestal georganiseerd rond hun eigen werkzaamheden. Daardoor wordt één klantprobleem al snel opgesplitst in verschillende rapportages, KPI’s en backlogs.

De interessante vraag is daarom: hoeveel stappen zitten er tussen het moment waarop een klantprobleem zichtbaar wordt en het moment waarop iemand bevoegd is er een prioriteit door te veranderen?

Van klacht naar roadmapbesluit

Laten we teruggaan naar de klacht waarmee dit artikel begon. Customer service registreert het contact, UX ziet hetzelfde probleem tijdens onderzoek en analytics laat zien dat mensen op dat punt afhaken. Wanneer die signalen los van elkaar blijven bestaan, leveren ze vooral meer kennis op.

Breng je ze bij elkaar, dan ontstaat iets waarop een team daadwerkelijk kan besluiten. Bijvoorbeeld:

Klanten haken tijdens het bestellen af omdat de informatie over levering en maatwerk onvoldoende duidelijk is. Dit zorgt voor extra servicecontact, onzekerheid tijdens het beslismoment en mogelijk gemiste omzet.

Dat is iets anders dan drie losse observaties. Het is een hypothese die tijdens refinement of prioritering kan worden besproken:

• Welke klanten worden geraakt?
• Hoe groot lijkt het probleem?
• Welk team kan de oorzaak aanpakken?
• En hoe bepalen we achteraf of de interventie werkte?

Het productteam kan vervolgens besluiten een bestaande prioriteit aan te passen. UX ontwerpt een oplossing. CRO of onderzoek helpt de aanname te valideren. Customer service ziet na invoering of het aantal vragen afneemt. Die uitkomst wordt vervolgens opnieuw onderdeel van de kennis over het probleem.

De afzonderlijke activiteiten bestaan in veel organisaties al, maar de winst zit in de verbinding ertussen.

Wat er bij Beerwulf veranderde

Bij Beerwulf zag ik hoe groot het verschil kan zijn. We beschikten over informatie uit customer service, gebruikersonderzoek, reviews, websitefeedback en verschillende marketingprogramma’s. Aan signalen dus geen gebrek.

Toch keek ieder team vooral naar zijn eigen deel van de ervaring. Het e-mailteam optimaliseerde campagnes op opens, clicks en conversie. Customer service analyseerde contactredenen. UX onderzocht waar klanten op de website vastliepen. Vanuit iedere discipline waren de keuzes logisch.

Toen we die inzichten bij elkaar brachten, zagen we een ander patroon. Klanten ontvingen vanuit verschillende programma’s communicatie die afzonderlijk relevant leek, maar gezamenlijk voor herhaling en onnodige druk zorgde. De ene journey hield onvoldoende rekening met wat een klant kort daarvoor via een andere journey had ontvangen.

We brachten de signalen daarom samen in een gedeeld insightssysteem en koppelden ze aan een gezamenlijke UX-metric. Daardoor veranderde ook de vraag tijdens prioritering. We keken minder naar welke individuele e-mail het beste presteerde en meer naar de totale communicatiedruk voor de klant.

Op basis daarvan werden journeys samengevoegd, berichten verwijderd en contactmomenten opnieuw ingericht. Het aantal e-mails dat klanten ontving daalde met ongeveer 50 procent. Belangrijker vond ik dat marketing, UX en service daarna vanuit dezelfde klantcontext naar nieuwe keuzes konden kijken. We verzamelden dus geen extra feedback, we veranderden de route die bestaande feedback door de organisatie aflegde.

Drie lessen die Experienceteams kunnen gebruiken

In The Phoenix Project (affiliate) worden drie principes beschreven die belangrijk zijn binnen DevOps: Flow, Feedback en Continuous Learning. Juist omdat ze zo eenvoudig zijn, vind ik ze bruikbaar om naar Experiencewerk te kijken.

1. Verkort de weg van signaal naar uitvoering

Flow gaat over de beweging van werk door het hele systeem. Voor Experienceteams betekent dit dat relevante klantproblemen beschikbaar moeten zijn op het moment dat werk wordt geprioriteerd.

Een servicethema dat eerst in een maandrapport verschijnt, daarna door een CX-team wordt geanalyseerd en vervolgens via een presentatie bij Product terechtkomt, heeft een lange doorlooptijd. Iedere overdracht vergroot de kans dat context verdwijnt.

Een centrale insightsrepository kan helpen, zeker wanneer die aansluit op Jira, Airtable of een productbacklog. Het doel is daarbij niet om van iedere klacht automatisch een ticket te maken. Het doel is dat terugkerende patronen tijdens refinement zichtbaar zijn, inclusief de onderliggende signalen en mogelijke impact.

2. Zorg dat feedback ook terugkomt

Veel Voice of the Customer-programma’s organiseren vooral de beweging van klant naar organisatie. Een echte feedbackloop loopt ook de andere kant op.

De servicemedewerker die een probleem signaleerde moet kunnen zien wat ermee gebeurde. De onderzoeker moet weten welke aanbeveling is uitgevoerd. En het productteam moet na livegang kunnen zien of de oorspronkelijke frictie daadwerkelijk afnam.

Dat hoeft geen nieuw rapport op te leveren. Vaak zijn vier vragen voldoende: welk probleem wilden we oplossen, wat hebben we veranderd, wat zien we nu en wat besluiten we op basis daarvan?

De jaarlijkse DORA-onderzoeken kijken niet voor niets naar de samenhang tussen snelheid, stabiliteit, cultuur en leren. Snel signaleren heeft weinig waarde wanneer na uitvoering niemand meer terugkijkt.

3. Behandel iedere oplossing als een aanname

Continuous Learning betekent dat een verandering doorgaat na livegang. Iedere oplossing blijft een aanname totdat zichtbaar wordt welk effect zij heeft gehad. Daarmee wordt experimentatie breder dan A/B-testen. Soms past een gecontroleerd experiment. In andere situaties geeft gebruikersonderzoek, een prototype, procesdata of een vergelijking van servicecontacten sneller antwoord.

De kern is steeds hetzelfde: vooraf bepalen welk gedrag of resultaat moet veranderen en daarna controleren of dat inderdaad gebeurde.

Onderzoek en CRO leveren daarmee niet alleen bewijs vóór een beslissing. Ze helpen ook beoordelen of een genomen beslissing in de praktijk standhoudt.

Begin klein in de bestaande werkwijze

Daarvoor is geen grote reorganisatie nodig. Je kunt beginnen met één terugkerend klantprobleem en volgen hoe dat door de organisatie beweegt.

• Waar ontstaat het eerste signaal?
• Welke andere bronnen kennen hetzelfde probleem?
• Wanneer komt het onderwerp terecht bij iemand die een prioriteit kan veranderen?
• Wie wordt eigenaar van de interventie?
• En komt het resultaat daarna terug bij de mensen die het probleem oorspronkelijk zagen?

Een vast overleg tussen bijvoorbeeld Product, Service, UX en Analytics kan al voldoende zijn om die beweging zichtbaar te maken. Bespreek daar een beperkt aantal klantproblemen waarvoor meerdere signalen bestaan. Bepaal per probleem wat de volgende beslissing is en wie daar eigenaar van wordt. In het volgende overleg komt het onderwerp alleen terug wanneer er nieuwe informatie of een besluit ligt.

Zo ontstaat langzaam iets wat in veel organisaties ontbreekt: organisatiegeheugen. Teams zien welke aannames eerder zijn onderzocht, waarom bepaalde keuzes zijn gemaakt en wat daarvan het effect was.

En AI?

AI kan binnen zo’n werkwijze helpen om grote hoeveelheden feedback te groeperen, patronen te herkennen en mogelijke verklaringen sneller zichtbaar te maken. Ik gebruik het daarom graag als artificial inspiration: ondersteuning bij het zien en onderzoeken van mogelijkheden.

Maar de belangrijkste stap blijft menselijk en organisatorisch. Iemand moet besluiten dat een signaal belangrijk genoeg is om een bestaande prioriteit te veranderen. Als die route ontbreekt, zorgt AI vooral voor snellere analyse van problemen die vervolgens op dezelfde plek blijven liggen.

Wat ik vooral van DevOps meeneem

Ik denk dat Experienceteams veel minder behoefte hebben aan nóg een nieuw framework dan aan kortere verbindingen tussen wat klanten ervaren en waar de organisatie haar keuzes maakt.

Pak daarom eens één probleem waarvan iedereen al weet dat het bestaat en volg het van eerste signaal tot roadmapbesluit en terug. De plekken waar het onderweg vertraagt of verdwijnt, vertellen waarschijnlijk meer over je CX-volwassenheid dan een nieuwe journey map.

De waarde van klantinzicht zit uiteindelijk in het moment waarop iemand er een andere beslissing door neemt.