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. Their history is scattered across webshop, ticketing system and accounts. 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 and a customer history that does not add up 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 discrepancies appear faster than you can clear them away.
Every standalone system builds its own version of the customer
Duplicates and discrepancies appear wherever customer details are entered or updated in more than one place. A customer fills in a form and is then typed into the CRM by hand as well, with a small spelling mistake in the name. An address change is applied in one system but not in the other. A migration or merger combines two databases without deduplicating. And systems store the same detail differently: one holds a date as 01-06-2026, the other as 2026/06/01.
None of those moments feels like a mistake, and that is exactly why the problem grows quietly with your organisation. The more systems and entry channels you have, the faster the profiles drift apart.
Where customer history comes apart
Most conflicts arise between systems that each know part of the customer but are rarely aligned:
- Webshop and CRM: purchases stay in the webshop, so sales lacks the context on a customer.
- Accounting and CRM: invoice and contact details diverge as soon as a customer changes address or contact person.
- Customer service and CRM: tickets are not attached to the customer record, so an account manager does not know what a customer has been through.
- Marketing and CRM: unsubscribes live only in the mailing system, so elsewhere you keep emailing someone who opted out, a GDPR risk.
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 every time:
- 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 just as reliable as good ones. What goes wrong when you keep steering by them 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. Useful work, but it is maintenance, not a solution. As long as systems create customer profiles independently, the pile starts growing again the next day.
The same goes for a one-off migration to a new system: the data moves across neatly, but nobody arranges what happens when something changes afterwards. Merging once is not synchronising continuously, and only the second keeps the customer history correct.
The structural way to prevent duplicates is to designate one system as the source for each piece of data and let the rest follow. That does not mean everything has to sit in one system: the CRM can lead for contact details, the accounts for invoices and the webshop for orders, as long as each piece of data is created or changed in one place and then updated everywhere automatically. You arrange that with API integrations, the connection points software uses to exchange data. Where nothing is retyped, no second version can appear. That is how we worked for Stichting DOEN: a family of fund websites connected to the financial system and the system in which applications are assessed.
How to tackle it in existing systems
A customer history that has drifted apart for years is not put right in an afternoon. What works in practice, in this order:
- Map which systems hold customer data and which fields overlap.
- Compare the sources: where are the biggest discrepancies and how old is the data?
- Merge duplicates and compile one complete version per customer from the most reliable sources.
- Designate a leading system for each piece of data, for example the CRM for contact details.
- Set up synchronisation through API integrations, so a change in the leading system automatically reaches every other system.
- Add validation rules at entry, so a new profile is first checked against what already exists and formats stay consistent.
The order is deliberate: start with the technology and you only synchronise the confusion faster.
A client portal as the visible front
If customers regularly ask about their orders, invoices or pending applications, or want to update their own details, a client portal is a logical next step after the integrations. Such a portal does not copy data; it retrieves it through the same integrations from the systems where it belongs and shows it in one place. Read more under web applications and portals.
To get a grip on this, start with the question of which system should lead for which piece of data. After that, the integration is implementation work. We have been developing API integrations for more than ten years for organisations that need to trust their view of the customer. Wrestling with this question? We are happy to think it through with you.