The same customer sits in your CRM as Jansen B.V., in your accounting package as Jansen BV and on the mailing list under a second email address. Three profiles, one customer, and none of the three is complete. It looks like a tidy-up job for a quiet Friday afternoon, but if all you do is clean up, the duplicates will be back within a few months.
That is because duplicate customer profiles are rarely a data-entry problem and almost always an integration problem. As long as your systems each maintain their own customer records without exchanging data, new duplicates appear faster than you can clear them away. So first the damage, then the approach that keeps working.
Every standalone system builds its own version of the customer
Duplicates appear wherever customer details are entered in more than one place. A customer fills in a form and is then typed into the CRM by hand as well. A colleague creates a profile that already exists, with a small spelling mistake in the name. A migration or merger combines two databases without deduplicating. And customers sign up through different channels, each with a different email address.
None of those moments feels like a mistake, and that is exactly why the problem grows quietly along with your organisation. The more systems and entry channels you have, the faster the profiles drift apart.
The damage shows up in your figures, your costs and your invoices
One customer who appears twice in your records counts double everywhere. The consequences surface in the same places time and again:
- Reports get distorted: the same customer counts twice in revenue figures and segmentations, so you steer by numbers that are wrong.
- Communication goes off the rails: the same mailing lands on the same doormat twice, or two profiles each tell a different story about a customer’s status.
- Invoices and deliveries are at risk: an address change applied to only one profile sends post and parcels the wrong way.
- Staff spend their time cleaning up instead of helping customers: working out which version is correct is invisible, recurring work.
The first point is especially treacherous, because figures from a polluted customer database look every bit as reliable as good ones. What goes wrong when you keep steering by them anyway is covered in our article on making decisions on inconsistent data.
The customer notices before you do
To the customer, a duplicate profile feels like an organisation that does not know them. They explain who they are at every contact, because their history sits on the other profile. They receive an offer for something they already bought last month. Each of those moments is small, but together they erode the trust your team works on every day. And this part of the damage never shows in a dashboard: customers rarely complain about a duplicate mailing, they quietly factor it in.
Deduplication fixes the past, integration fixes the future
You remove existing duplicates with a one-off deduplication run: compare records on name, email address and phone number, and decide for each conflict which details win. Many CRM packages include tools for this. Useful work, but it is maintenance, not a solution. As long as systems create customer profiles independently of each other, the pile starts growing again the next day.
The structural way to prevent duplicates is to designate one system as the source for each piece of data and let the rest follow. You arrange that with API integrations, the connection points modern software ships with for exchanging data: a customer created or changed in one place is updated everywhere automatically. That is how we have been building for Stichting DOEN, the fund of the Nationale Postcode Loterij and the VriendenLoterij, since 2025: a family of six fund websites on a single platform, connected to their financial and grant management systems. Applications land in the right place without retyping, and where nothing is retyped, no second version can appear.
If you want to get a grip on this, start not with the technology but with the question of which system should lead for which piece of data. After that, building the integration is implementation work. Since 2001 we have been developing API integrations for organisations that need to be able to trust their view of the customer. Wrestling with this question? We are happy to think it through with you.