Wat er verandert als alles hetzelfde klantrecord deelt

Klantsoftware heeft de neiging om na verloop van tijd uit elkaar te vallen.

Bestellingen gaan in het ene systeem. Loyaliteitspunten leven ergens anders. Campagnes gebruiken een aparte doelgroeplijst. Support heeft z'n eigen inbox. Boekingen komen misschien uit weer een ander tool.

Elk systeem werkt goed genoeg op zichzelf. De problemen beginnen wanneer een echte klant ertussen beweegt.

We hebben veel tijd gestoken in dit deel van Fidelect: ervoor zorgen dat loyaliteit, commerce, communicatie en de dagelijkse operatie hetzelfde klantrecord gebruiken.

Het klinkt als een databeslissing. Het verandert het product op heel praktische manieren.

Het team stopt met het verhaal bij elkaar puzzelen

Stel je een klant voor die een bestelling heeft geplaatst, een beloning heeft gebruikt, contact heeft opgenomen met support en een nieuw bezoek heeft geboekt.

Als die acties in aparte tools leven, moet een teamlid de klant meerdere keren opzoeken. E-mailadressen kunnen verschillen. Telefoonnummers kunnen anders zijn opgemaakt. Een account kan gedupliceerd zijn.

Zelfs als de records kloppen, is de tijdlijn verspreid.

Met een gedeeld record verschijnen de bestelling, de inwisseling, het gesprek en de boeking rond dezelfde persoon. Het team kan zien wat er is gebeurd zonder de klant te vragen het opnieuw uit te leggen.

Dit is simpelweg context. Het scheelt een verrassende hoeveelheid verwarring.

Loyaliteitsregels kunnen echte activiteit gebruiken

Een loyaliteitsprogramma heeft betrouwbare events nodig.

Punten kunnen komen uit aankopen, verwijzingen, bezoeken, boekingen, achievements of een handmatige aanpassing door het team. Elk event heeft z'n eigen timing en faalscenario's.

Een bestelling kan worden geannuleerd. Een betaling kan mislukken. Een verwijzing kan ongeldig zijn. Een boeking kan worden gemist.

Als loyaliteit het operationele record deelt, kan het systeem op die veranderingen reageren. Punten worden toegekend als het juiste event is afgerond. Een terugboeking volgt op een restitutie. Een tier wordt bijgewerkt op basis van dezelfde historie die voor rapportage wordt gebruikt.

De klant ziet een saldo waar een traceerbare reden achter zit.

Campagnes worden makkelijker te richten

Doelgroeptargeting wordt vaag als campagnedata van plek naar plek wordt gekopieerd.

Een segment genaamd "recente klanten" is misschien gebaseerd op de export van vorige week. Een win-backcampagne kan iemand bevatten die gisteren via een ander kanaal heeft gekocht. Een lidmaatschapsbericht kan mensen bereiken van wie het abonnement al is verlopen.

Gedeelde data vermindert die drift.

Segmenten kunnen actuele bestelactiviteit, tier, punten, lidmaatschapsstatus, boekingshistorie, berichtbetrokkenheid of andere details gebruiken die al aan de klant hangen.

Het wordt ook makkelijker om een nuttige vraag te beantwoorden: waarom heeft deze persoon dit bericht ontvangen?

Support ziet wat de klant ziet

Supportgesprekken beginnen vaak met ontbrekende context.

"Mijn punten kloppen niet."

"Mijn coupon werkte niet."

"Waar is mijn bestelling?"

Simpele berichten met meerdere mogelijke oorzaken.

Als support dezelfde bestelling, beloning, coupon en puntenhistorie kan zien, kan het eerste antwoord nuttig zijn. De medewerker hoeft minder te zoeken. De klant besteedt minder tijd aan het sturen van screenshots.

We houden wel de permissies in het oog. Een gedeeld klantrecord zou niet moeten betekenen dat elk teamlid alles ziet. Rollen en audit logs worden belangrijker naarmate activiteit meer verbonden raakt.

Rapportage wordt minder glibberig

Rapporten spreken elkaar vaak tegen omdat ze verschillende versies van hetzelfde event tellen.

Het commercetool telt een bestelling. Het loyaliteitstool telt toegekende punten. Het campagnetool claimt een conversie. Finance boekt later een restitutie.

Als die systemen nooit met elkaar worden vergeleken, driften de cijfers langzaam uit elkaar.

Een gedeeld record geeft rapporten een gezamenlijk pad terug naar de onderliggende activiteit. Campagneresultaten kunnen verwijzen naar bestellingen. Beloningskosten kunnen verwijzen naar inwisselingen. Klantwaarde kan de historie bevatten die het bedrijf heeft besloten bij te houden.

De cijfers hebben nog steeds zorgvuldige definities nodig. Eén datamodel lost niet elke rapportagediscussie op. Het geeft het team een duidelijkere plek om ze op te lossen.

Identiteit is het lastige deel

Klanten komen niet altijd met een netjes account aan.

Ze kopen misschien aan de balie met een telefoonnummer, bestellen online met een e-mailadres en worden later lid. Families delen misschien een nummer. Het team kan gegevens verkeerd invoeren. Geimporteerde records bevatten mogelijk al duplicaten.

Het samenvoegen van die identiteiten vereist terughoudendheid.

Een onjuiste samenvoeging is erger dan een duplicaat. Het kan privéinformatie blootstellen of activiteit aan de verkeerde persoon toewijzen.

We behandelen matching als een proces met betrouwbaarheidsniveaus, verificatie en menselijke beoordeling waar nodig. Sommige records moeten apart blijven totdat er genoeg bewijs is.

Eén record schept verantwoordelijkheid

Het verbinden van klantactiviteit maakt het product makkelijker te gebruiken. Het verhoogt ook de kosten van onzorgvuldige keuzes.

Permissies moeten specifiek zijn. Verwijder- en exportverzoeken moeten verbonden data bereiken. Audit logs hebben genoeg detail nodig om veranderingen te verklaren. Bewaartermijnen moeten consistent worden toegepast.

Dit werk zit onder de zichtbare features.

De meeste klanten zullen nooit aan het record zelf denken. Ze zullen merken dat hun punten worden bijgewerkt, dat hun bestelling vindbaar is en dat support al weet waar ze het over hebben.

Dat is het resultaat waar we naartoe werken.