Dezelfde klant staat in je CRM als Jansen B.V., in je boekhoudpakket als Jansen BV en op de mailinglijst met een tweede e-mailadres. Drie profielen, één klant, en geen van de drie is compleet. Zijn historie ligt verspreid over webshop, ticketsysteem en boekhouding. Het lijkt een opruimklus voor een rustige vrijdagmiddag, maar wie alleen opschoont, ziet de duplicaten binnen een paar maanden terugkomen.
Dubbele klantprofielen en een klanthistorie die niet klopt, zijn namelijk zelden een invoerprobleem en bijna altijd een koppelingsprobleem. Zolang je systemen elk hun eigen klantenbestand bijhouden zonder gegevens uit te wisselen, ontstaan nieuwe afwijkingen sneller dan je ze kunt wegwerken.
Elk los systeem bouwt zijn eigen versie van de klant
Duplicaten en afwijkingen ontstaan overal waar klantgegevens op meer dan één plek worden ingevoerd of bijgewerkt. Een klant vult een formulier in en wordt daarna nog eens handmatig in het CRM gezet, met een kleine spelfout in de naam. Een adreswijziging wordt in het ene systeem doorgevoerd en in het andere niet. Een migratie of fusie voegt twee databases samen zonder te ontdubbelen. En systemen slaan hetzelfde gegeven anders op: het ene een datum als 01-06-2026, het andere als 2026/06/01.
Geen van die momenten voelt als een fout, en juist daarom groeit het probleem stil mee met je organisatie. Hoe meer systemen en invoerkanalen, hoe sneller de profielen uit elkaar lopen.
Waar de klanthistorie uit elkaar loopt
De meeste conflicten ontstaan tussen systemen die elk een deel van de klant kennen, maar zelden op elkaar zijn afgestemd:
- Webshop en CRM: aankopen blijven in de webshop, dus sales mist de context van een klant.
- Boekhouding en CRM: factuur- en contactgegevens lopen uiteen zodra een klant van adres of contactpersoon wisselt.
- Klantenservice en CRM: tickets hangen niet aan de klantkaart, dus een accountmanager weet niet wat een klant al heeft meegemaakt.
- Marketing en CRM: afmeldingen staan alleen in het mailsysteem, dus elders blijf je iemand mailen die zich al heeft afgemeld, een AVG-risico.
De schade zit in je cijfers, je kosten en je facturen
Eén klant die twee keer in je administratie staat, telt overal dubbel mee. De gevolgen komen op vaste plekken terug:
- Rapportages vertekenen: dezelfde klant telt dubbel mee in omzetcijfers en segmentaties, dus je stuurt op getallen die niet kloppen.
- Communicatie ontspoort: dezelfde mailing valt twee keer op dezelfde mat, of twee profielen vertellen elk een ander verhaal over de status van een klant.
- Facturen en leveringen lopen risico: een adreswijziging die maar in één profiel is doorgevoerd, stuurt post en pakketten de verkeerde kant op.
- Medewerkers ruimen op in plaats van dat ze klanten helpen: uitzoeken welke versie klopt is onzichtbaar, terugkerend werk.
Vooral dat eerste punt is verraderlijk, omdat cijfers uit een vervuild klantenbestand er net zo betrouwbaar uitzien als goede cijfers. Wat er misgaat als je er toch op blijft sturen, lees je in ons artikel over beslissen op inconsistente data.
De klant merkt het eerder dan jij
Voor de klant voelt een dubbel profiel als een organisatie die hem niet kent. Hij legt bij elk contact opnieuw uit wie hij is, omdat zijn historie aan het andere profiel hangt. Hij krijgt een aanbieding voor iets dat hij vorige maand al afnam. Elk van die momenten is klein, maar samen ondergraven ze het vertrouwen waar je team dagelijks aan werkt. En dit deel van de schade zie je niet in een dashboard: klanten klagen zelden over een dubbele mailing, ze wegen het stilzwijgend mee.
Ontdubbelen lost het verleden op, koppelen de toekomst
Bestaande duplicaten haal je weg met een eenmalige ontdubbelactie: records vergelijken op naam, e-mailadres en telefoonnummer, en per conflict bepalen welke gegevens winnen. Nuttig werk, maar het is onderhoud, geen oplossing. Zolang systemen los van elkaar klantprofielen aanmaken, begint het opstapelen de dag erna opnieuw.
Hetzelfde geldt voor een eenmalige migratie naar een nieuw systeem: de gegevens gaan netjes mee, maar niemand regelt wat er gebeurt als er daarna iets wijzigt. Eenmalig samenvoegen is geen doorlopend synchroniseren, en alleen het tweede houdt de klanthistorie kloppend.
Structureel voorkom je duplicaten door per gegeven één systeem als bron aan te wijzen en de rest te laten volgen. Dat betekent niet dat alles in één systeem moet staan: het CRM kan leidend zijn voor contactgegevens, de boekhouding voor facturen en de webshop voor bestellingen, zolang elk gegeven maar op één plek ontstaat of wijzigt en daarna automatisch overal wordt bijgewerkt. Dat regel je met API-koppelingen, de aansluitingen waarmee software gegevens uitwisselt. Waar niets wordt overgetypt, ontstaat ook geen tweede versie. Zo werkten we ook voor Stichting DOEN: een familie van fondsenwebsites, gekoppeld aan het financiële systeem en het systeem waarin aanvragen worden beoordeeld.
Zo pak je het aan in bestaande systemen
Een klanthistorie die al jaren uit elkaar loopt, zet je niet in één middag recht. Wat in de praktijk werkt, in deze volgorde:
- Breng in kaart welke systemen klantgegevens bevatten en welke velden elkaar overlappen.
- Vergelijk de bronnen: waar zitten de grootste afwijkingen en hoe oud is de data?
- Voeg duplicaten samen en stel per klant één complete versie samen uit de betrouwbaarste bronnen.
- Wijs per gegeven een leidend systeem aan, bijvoorbeeld het CRM voor contactgegevens.
- Richt synchronisatie in via API-koppelingen, zodat een wijziging in het leidende systeem automatisch overal doorkomt.
- Stel validatieregels in bij invoer, zodat een nieuw profiel eerst wordt vergeleken met wat er al is en formaten gelijk blijven.
De volgorde is bewust: wie met de techniek begint, synchroniseert de verwarring alleen sneller.
Een klantportaal als zichtbare voorkant
Vragen klanten regelmatig naar hun bestellingen, facturen of lopende aanvragen, of willen ze hun gegevens zelf bijwerken, dan is een klantportaal een logisch vervolg op de koppelingen. Zo’n portaal kopieert geen data, maar haalt die via dezelfde koppelingen op uit de systemen waar ze thuishoren en toont ze op één plek. Meer daarover lees je bij webapplicaties en portalen.
Wil je hier grip op krijgen, begin dan bij de vraag welk systeem voor welk gegeven leidend moet zijn. Daarna is de koppeling het uitvoerende werk. We ontwikkelen al meer dan tien jaar API-koppelingen voor organisaties die op hun klantbeeld moeten kunnen vertrouwen. Loop je rond met dit vraagstuk? We denken graag met je mee.