Customer Journey Mining, hoe werkt dat nu?

  4 minuten

Hoe gaat dat nu in het echt met die data en die analyses voor Customer Journey Mining?

In deze blog neem ik je graag mee in de relatie tussen data en analyse. Die kan namelijk grote gevolgen hebben voor de verhoudingen tussen data engineers en data analisten en daarmee voor de manier waarop je data analyse projecten moet aanvliegen.

Eenvoud voor de klant, snellere afhandeling van het proces en verlaging van de kosten zijn belangrijke voorwaarden voor organisaties om relevant te kunnen te blijven. Onder de noemer selfservice, nodigen we de klant dan ook in toenemende mate uit om deel te nemen aan het proces. De klant die bewust in het proces aanwezig is, maakt ook dat het belangrijker wordt voor organisaties om integraal te sturen op alle aspecten van de klantreis (Customer Journey).

Sturen impliceert richting. Om te weten welke interventies er in een proces nodig zijn, willen we eerst objectief vaststellen waar de problemen liggen. Er komen meer en meer gereedschappen of tools beschikbaar om ons daarbij te helpen. De vakman die de gereedschappen hanteert noemen we de data analist.

Een data analist is afhankelijk van de data die hij heeft om zijn analyses te kunnen uitvoeren en daarmee is de relatie met degene die de data aanlevert essentieel (vaak de data engineer).

Allereerst een aantal vertrekpunten bij Customer Journey analyses. De data analist benadert een klantreis als proces. Hij maakt vooral gebruik van de volgende analyses tijdens een verbetercyclus:

  • Pareto analyses – Gebruiken we om in te zoomen op een specifiek deel van de Customer Journey of specifieke journeys waar de problemen het grootst zijn
  • Process Mining – Gebruiken we om een goed model te vormen van de werkelijk klantreizen. Op die manier kunnen we binnen de geselecteerde klantreizen inzoomen op de specifieke problemen om vandaar de root-causes te vinden.
  • Statistische analyses – Helpen ons om te onderbouwen wat de impact van de problemen is en wat de verwachte verbetering van het wegnemen van de root-cause is. Na het plegen van de interventie zullen we op deze manier met nieuwe data natuurlijk ook controleren of de interventie succesvol was.

 

We leunen op de data

De beschreven analyses staan of vallen met de kwaliteit van de data. Echter, bij veel organisaties is de kwaliteit van die data niet ideaal. In de figuur hieronder is een simpele Customer Journey geschetst, inclusief een paar voorbeelden van veel voorkomende problemen.

Data wordt zelden vastgelegd met het doel om te analyseren. Daardoor is de standaardisatie vaak laag. Dit probleem komt in het voorbeeld niet naar voren, maar je moet dan bij voorbeeld denken aan systeemlogging die primair bedoeld is voor technisch systeembeheer.

  • Soms bestaat de data die we het interessantst vinden uit vrije tekst. In het voorbeeld willen we graag weten welke antwoorden op welke vragen het meest succesvol zijn. In die gevallen maken we gebruik van text mining.
  • Data wordt meestal vastgelegd door mensen. Mensen maken wel eens fouten. We maken mee dat tot wel 20% van de waarden in een veld onjuist zijn. Vooral velden die door de invuller niet gezien worden als waarde toevoegend, worden slecht ingevuld. In het voorbeeld wordt bijvoorbeeld de classificatie van de vraag vastgelegd voor verantwoordingsdoeleinden. De kans is groot dat de medewerker daar het nut en noodzaak niet van inziet en de categorie overig gebruikt.
  • Vaak leiden we de data af uit velden die met een ander doel vastgelegd zijn. De vastgelegde classificatie heeft als doel verantwoording. De kans is groot dat we voor onze analyse eigenlijk een andere classificatie hadden gewenst. We zoeken dan naar een vertaling die zo goed mogelijk is. In de praktijk is dat niet altijd 100%.
  • De bovenstaande dataproblemen zijn generiek voor alle datagerichte analyses. Binnen Customer Journey Management willen we bovendien de klantreis in samenhang zien: we willen de activiteiten van klanten over de verschillende kanalen heen kunnen volgen. Dat zorgt er voor dat we data uit verschillende systemen zoals: website, e-mail en primair systeem willen koppelen. Dit laatste brengt nieuwe technische en juridische uitdagingen. In ons voorbeeld start de klant met een webbezoek en stuurt vervolgens een mail. Hoe weten we dat de klant die bij het IP-adres van het webbezoek dezelfde klant is als die met het e-mail adres van de mail? Daar zijn oplossingen voor, maar in de praktijk weten we het zelden 100% zeker.

De data engineer streeft ernaar om ondanks de beschreven problemen tot een dataset te komen waar de data analist optimaal analyses mee kan doen. Hij brengt data samen, bepaalt de betrouwbaarheid, schoont data op en herstructureert het tot een dataset waar geschikt voor analyse. Gebreken in de data worden niet onder de mat geveegd, maar in de gebruiksaanwijzing opgenomen.

 

Dansen om de data

Tot zover de context waarbinnen data analisten en data engineers werken. Bijna aan het einde van deze blog komen we dan tot de essentie: communicatie. De gebruiksaanwijzing die bij de data geleverd wordt door de data engineer is zelden volledig. Sommige problemen kun je namelijk pas vinden door de data inhoudelijk te vergelijken met het verloop van de Customer Journey. Dat laatste doen we pas tijdens de analyses.

customer journey voorbeeld

Tijdens initiële analyses worden door de data analist vaak uitkomsten gevonden die “niet kunnen kloppen”. Vaak doen ze dat dan ook niet. Zulke uitkomsten checken we dus met inhoudsdeskundigen en blijkt dat er nog problemen in de data zitten. Terug naar de data engineer die met de extra kennis een nieuwe verbeterde dataset beschikbaar stelt. Waar mogelijk nieuwe onvolkomenheden in gevonden worden.

De belangrijke kernwaarden voor die communicatie zijn:

  • Commitment en focus: we hebben een gemeenschappelijk doel voor ogen en zijn allen bereid om daar in te investeren
  • Durf: ook tegenvallende resultaten zijn belangrijk want ook daarmee leren we veel
  • Openheid: We delen beperkingen aan de data zodat we weten wat we er wel en wat we er niet mee kunnen doen. Bovendien delen we die beperkingen in het kader van data governance met de organisatie zodat die daar mogelijk de ICT of de werkwijze op aan kan passen.
  • Respect: Data engineer en data analist zijn beiden deel van hetzelfde team. Dat kan alleen als er werkelijk respect is voor het handelen, maar ook voor de beperkingen van de ander.

Niet geheel toevallig zijn dit ook de kernwaarden van Scrum. Het beschikbaar stellen van data en het analyseren van die data is bij initiële analyses een iteratief proces dat zich prima binnen de Scrum methodiek laat vangen.

Data engineer en data analist zijn daarin partners in een dans waar iedereen van hoopt dat hij effectief en dus kort is. De doorslaggevende factor voor die effectiviteit is communicatie.

 

 

cta
Deel dit artikel