Customer data platform engineering
One customer record across sales, support, billing and the till — with deduplication, clear field ownership and a migration path off the legacy CRM that does not lose history.
What a single customer record actually takes
Contact, account and hierarchy models
Private customers, companies, subsidiaries, sites and contact persons modelled once, so a B2B account and a household do not have to share the same flat record.
Deduplication and matching rules
Fuzzy matching on names, registry codes, phone numbers and addresses, with confidence thresholds and a review queue for the cases that should not be merged automatically.
Field ownership and conflict rules
Billing owns the invoice address, the till owns the loyalty balance, the CRM owns the consent flags. Writing that down is what stops the last system to write from winning.
Customer 360 views
Contracts, invoices, tickets, purchases and consents on one screen, assembled from the systems that own them rather than copied into a new silo.
Migration from legacy CRMs
Profiling before moving, so you know how much of the old data is duplicated, expired or unusable — and can decide what is worth carrying across.
Data quality monitoring
Ongoing checks on completeness, duplicates and stale records, reported to the people who own the data rather than to the team that built the platform.
Don’t see your challenge here? Talk to us about your project
The hard part is agreeing who owns which field
Deduplication is a solvable technical problem. The part that decides whether a customer data platform holds together is governance: which system is authoritative for each field, what happens when two of them disagree, and who is allowed to overrule the rule.
We run that as a working session with the people who actually maintain the data — finance, support, marketing, retail — before writing any synchronisation code. It is faster than discovering the disagreements in production.
- Golden record
- One authoritative view assembled from owning systems.
- Match review
- A queue for merges that should not happen automatically.
- History preserved
- Merges are reversible and fully audited.
- Consent-aware
- Consent travels with the record, not beside it.
- Event-driven
- Changes propagate as events, not nightly batches.
- Measured
- Data quality reported to the business, not the build team.
A bonus system that had to agree with the CRM, the tills and the online shop
Coop's lottery bonus system could only work if the customer record was the same one everywhere — in the CRM, at the cash register, in the receipt system and in the online shop. Getting the identity and the balance to agree across four systems, in real time, was the project; the lottery mechanics on top were comparatively simple.
Common questions
Do we need to replace our CRM to do this?
Usually not. In most cases the CRM stays and becomes one participant in a customer data layer, alongside billing and the till. Replacement becomes worth discussing only when the CRM cannot be extended or integrated at acceptable cost.
How do you handle duplicates that should not be merged?
Automatic merging is limited to high-confidence matches. Everything below the threshold goes to a review queue with the evidence shown side by side, and every merge is reversible with full history retained.
What about GDPR and consent?
Consent is modelled as part of the customer record from the start — per purpose, per channel, with version and timestamp — so deletion, export and objection requests can be answered from one place rather than chased across systems.
Let's talk about your customer platform
Tell us where your customer data sits today and which question you cannot currently answer about it. We will come back with an honest read on the model, the integration work involved, and what a realistic first phase looks like.
