Een CDP, een CRM en een warehouse draaien allemaal om de persoon
De platformen die je nu gebruikt, verschillen in hoeveel structuur ze vooraf vastleggen. Niet in waar ze omheen gebouwd zijn.
Een CDP kent in de regel één entiteit: de natuurlijke persoon. Een e-mailadres of telefoonnummer is de sleutel waarop je data samenvoegt op dat profiel. Alles wat je opslaat, slaat je op als eigenschap van een mens.
Een CRM is iets ruimer. Het individu, het bedrijf, de deal en een paar datapunten daaromheen. Ruimer, maar even vooraf bepaald.
Een datawarehouse dat je zelf inricht is het flexibelst, maar ook daar bepaalt iemand vooraf welke data erin gaat, welke niet en hoe die aan elkaar gerelateerd is. In de praktijk is dat IT, op basis van wat gebruikers op dat moment vroegen.
Alle drie gaan ervan uit dat je klantdata zich netjes laat ordenen rond de klant, en dat de vragen die je nu stelt dezelfde zijn als toen het systeem werd ingericht. Op drie punten loopt dat vast.
Liever kijken dan lezen?
In deze aflevering gaan Rutger en Tom dieper in op het verschil tussen een CDP, een CRM en een graph.
Het meeste dat relevant is voor je klant, gaat niet over je klant
Neem een luchtvaartmaatschappij. Je hebt klanten, je hebt een vloot, je hebt vluchten die van die vloot gebruikmaken zonder die vloot te zijn, en je hebt tickets.
Annuleer je een vlucht, dan gaat dat a priori over die vlucht. Het raakt de driehonderd mensen die erin zouden zitten, maar het gaat niet letterlijk over hen.
Voorraad is hetzelfde verhaal. In een persoonsgebonden model moet je per persoon bijhouden wie mogelijk geïnteresseerd is en wat de actuele stand is. De voorraad zelf hoort bij het product, niet bij een mens. Dat geldt ook voor de openingstijden van een winkel, de status van een bestelling, een review, een vestiging, een polis.
Dit is geen randgeval. Dit is het grootste deel van wat je nodig hebt om iets zinnigs tegen een klant te zeggen.
In een model waarin elk datapunt aan een persoon moet hangen, gebeurt er dan een van twee dingen. Het gaat naar een ander systeem. Of het wordt erin gepropt waar het net past: we zien bedrijven die hun winkels als klantrecord in hun CRM zetten, omdat ze die gegevens wel in datzelfde platform willen hebben en het platform er niet voor gemaakt is.
Dat is geen slordigheid, dat is de enige uitweg die het model biedt.
Gescheiden systemen bewaren data, geen verbanden
Splitsen heeft een prijs, en dat is niet de opslag. Het is het verband.
Staat je reviewer op plek A en je klant op plek B, of je vlucht op A en je klant op B, dan valt het effect tussen die twee niet te vinden. Ze leven niet samen. Je kunt de vraag niet stellen, laat staan het antwoord ontdekken.
Een concreet voorbeeld. Wie heeft een negatieve review achtergelaten? Rond welke winkel centreren die reviews zich? Is er een regionaal effect? Wie wonen daar in de buurt, en wie van hen heeft al eens gekocht?
Elke stap is een relatie tussen datapunten die in gescheiden systemen niet bestaat. Dus wordt het een export uit Trustpilot, een merge, een ticket, een sprint, en een inzicht dat aankomt als het momentum weg is. Dat wachten is het symptoom waar mensen over klagen. De oorzaak is dat de relatie nooit is vastgelegd.
En zelfs binnen één systeem loop je vast. Zit alles als eigenschap op het klantrecord, dan heb je eenrichtingscausaliteit vastgelegd: dit gaat over deze klant. De verbanden tussen die datapunten onderling kun je niet goed ontdekken. Plus dat het traag is: zonder directionele relatie ga je bij vijf miljoen klanten vijf miljoen records door om te vinden wie een negatieve review schreef.
Dat zijn nog de known unknowns, de dingen waarvan je weet dat ze in de weg zitten. Daaronder ligt een laag unknown unknowns: wat je zou ontdekken als het wel bij elkaar stond.
En een vast model beweegt niet mee met je bedrijf
Een system of record voor klantgegevens blijft gemiddeld vijf tot zeven jaar in het applicatielandschap van een bedrijf staan.
Kijk naar wat er de afgelopen drie jaar met AI is gebeurd, en maak dan de voorstelling dat je nog zes jaar verder moet met een fundament waar je nu al tegen de pijnpunten aanloopt.
Je bedrijf verandert namelijk wel. Ben je verzekeraar en heb je tot nu toe alleen autoverzekeringen gedaan, dan is inboedel en opstal een nieuwe entiteit, met nieuwe relaties naar je bestaande dienstverlening en naar klanten per regio. In een vast model is dat een aanvraag, een migratie en een wachttijd, of je slaat het over.
AI agents hebben relaties nodig, geen profielen
Er is een gebruiker bijgekomen. Een mens wil een interface met knoppen, een AI agent wil een API of een abstractielaag daarboven zoals een MCP-server. Dat verschil is klein.
Wat niet klein is: een agent moet relaties kunnen volgen die niemand vooraf heeft bedacht. Je kunt hem niet los laten op je CDP, je CRM, je warehouse en je data lake met de opdracht om per systeem een miljoen records door te lopen en ergens een verband tussen X en Y te vinden.
Neem een vraag die makkelijk klinkt: wat zijn de openingstijden van de dichtstbijzijnde winkel? Daarvoor moet een agent weten wie iemand is, waar hij woont, wat de afstand tot je vestigingen is, en wat de openingstijden zijn. Die laatste staan niet vast: feestdagen verschuiven, bezetting dwingt aanpassingen af, en soms verruim je bewust. Je krijgt dus twee varianten. Een agent die eerst vraagt waar iemand woont en daarna alsnog het antwoord niet heeft. Of een agent die het in één vraag aan één plek ophaalt.
Vergelijk het met hoe je kennis aan een agent geeft. Je site crawlen, pdf's uploaden, je kennisbank koppelen, alles op één plek zodat hij het in één keer kan doorzoeken. Dat werkt. Voor klantgegevens is dat niet opeens anders.
In een graph is de relatie zelf het datapunt
Het Customer Context Platform is geen CDP, geen CRM en geen datawarehouse. Het zit ertussenin: een plek voor gestructureerde data die relevant is voor je klant zonder over je klant te hoeven gaan.
Stel je nodes voor, rondjes met een datapunt erin. Tussen die nodes liggen relaties. Een relatie kan één kant op gaan of twee kanten op, en als hij één kant op gaat wil je weten van welke node naar welke node.
Voor de luchtvaartmaatschappij betekent dat vier entiteiten naast elkaar in plaats van één profiel met alles eraan:
Klant → heeft → Ticket
Ticket → voor → Vlucht
Vlucht → uitgevoerd met → Toestel
Nieuwe entiteiten voeg je toe in de datamanager, en de relaties trek je daarna, of je ontdekt ze later. Dat laatste is het punt: je hoeft niet vooraf te weten hoe een datapunt zich verhoudt tot de rest.
Verwar het niet met een knowledge graph. Daar is de input fuzzy, stukjes tekst en pdf's, en breng je structuur aan in ongestructureerde data. Een CXP doet het omgekeerde: gestructureerde data op een ongestructureerdere manier verkenbaar maken.
Een segment hoort een vraag te zijn, geen project
Een segment wordt een vraag. Segmenten maken is nu een vooraf bepaalde oefening: je bedenkt zelf wat interessant zou kunnen zijn, configureert dat, en houdt een bakje klanten over. In een graph begin je bij de entiteit review, pakt de negatieve, en volgt de relatie naar de mensen. Je hoeft de vraag niet te bouwen om hem te kunnen stellen.
Techniek wordt een query. "Mensen die X kochten, kochten ook Y" viel tot voor kort in de categorie big data: alle events op een hoop, collaborative filtering erop, dan een recommendation op je site. In een graph is dat geen AI-toepassing meer. Het is graph traversal, een query die je in elkaar klikt.
Eén tellertje in plaats van een miljoen records. Stond er zes op voorraad en verkoop je er een, dan zet je het product op vijf en raak je verder niets aan. De relaties liggen er al, bijvoorbeeld naar mensen die het de afgelopen tien dagen in hun cart hadden en niet afrekenden.
Kleine vragen worden het waard. Zulke vragen sneuvelen nu op een effort-versus-value-afweging. Vijftig keer per dag is niet enorm en de inrichting kost te veel. Kost het antwoord bijna niets, dan doe je het wel, en tellen al die kleintjes op.
Verbanden ontdekken uit gesprekken. Haal je realtime inzichten uit je klantgesprekken, dan komen die hier terecht. Wist je al dat een bedrijf bestaat en dat een persoon bestaat, maar nog niet dat die persoon daar werkt, en zegt hij dat in een gesprek, dan leg je die relatie vast en weet je het de volgende keer. Dat voorbeeld kan een CRM ook aan. Het punt is dat je het kunt doortrekken naar entiteiten die je in een CRM of CDP helemaal niet kwijt kunt.
Segmenten die je zelf niet had bedacht. Ligt alles bij elkaar, dan kun je latente segmenten laten ontdekken in plaats van ze te verzinnen, en niet per definitie vanuit het klantperspectief.
Voorspellingen worden beter als de verbanden er al liggen
Als "mensen die X kochten, kochten ook Y" een query wordt, schuift de lat op voor wat je AI laat doen.
Binnen CXP trainen we per klant een apart model, dat we zelf from scratch hebben gebouwd. Qua architectuur lijkt het op een LLM, maar veel compacter en uitsluitend getraind op jouw data. Volledig air-gapped en uniek voor jou. Dat model voorspelt wat je naar iemand moet sturen, op welk moment, en hoe waarschijnlijk het is dat iemand gaat churnen.
In eigen tests met klanten zien we bij recommendations een twee keer hogere hit rate dan in de oude opzet.
Dat is niet alleen het dataplatform. Het model zelf is ook geavanceerder dan wat er op onze oude CDP lag. Wat het datamodel toevoegt, is dat de impliciete verbanden er al liggen. Die hoeft het model niet tijdens het leerproces zelf te ontdekken, dus het kan een stap verder leren.
Sleutelen kan ook. Business rules erover heen voor filtering, bijvoorbeeld bij derving: producten die binnen een maand van de plank af moeten, wil je in je recommendations meenemen ongeacht of ze de beste fit zijn. De basisvoorspellingen werken zonder dat je zelf logica aanlevert.
Niet elk bedrijf heeft een graph nodig
De eerste winst is niet flexibiliteit, het is dat je data bij elkaar staat. Die haal je ook met een warehouse, en dat is nog altijd beter dan tien systemen die niet naar elkaar kijken. Wij gaan een stap verder: bij ons hoeft die ene plek niet vooraf dichtgespijkerd te worden, en dat verschil merk je de eerste keer dat je bedrijf verandert.
Twee dingen waar we wel eerlijk over willen zijn.
Zijn je klantrelaties eenvoudig en stabiel, en weet je nu al welke velden je over vijf jaar nodig hebt, dan doet een CDP wat het moet doen. Dan kopen we je niets beters.
En een flexibel model repareert geen slechte input. Wordt er niets uit je gesprekken geëxtraheerd, dan heb je een lege graph in plaats van een lege tabel. De graph is de plek waar het landt, niet de reden dat het er komt.
CXP is de datalaag van het CM.com-platform
CXP is de datalaag van ons platform en staat open. Je koppelt het CRM, commerceplatform, ERP of warehouse dat je al gebruikt, in plaats van je stack te vervangen.
Wat wij eraan toevoegen en een los dataplatform niet kan: de gesprekken komen binnen over onze eigen kanaalinfrastructuur. De Conversational Router leest taal, intentie, sentiment en entiteiten uit die inkomende gesprekken en schrijft ze er realtime naartoe, ongeacht kanaal. Geen nachtelijke import, geen koppeling die je zelf moet bouwen. Aan de uitvoerkant lezen je business users en je HALO AI agents uit precies diezelfde context, en bovenop de graph draait per klant een eigen voorspelmodel.
Want AI is slechts zo slim als de context die het krijgt.
