A healthcare conglomerate grew through acquisition for fifteen years. Each acquisition brought its own CRM. Salesforce in three divisions. Microsoft Dynamics in two. HubSpot in one. A custom-built CRM in another. A legacy on-premise system that predated the cloud era in two more. By the time they counted, there were twelve distinct CRM systems holding customer data for overlapping populations with no shared identifier, no common schema, and no reconciliation mechanism.
The customer was sometimes the patient, sometimes the referring physician, sometimes the insurance payer, and sometimes the employer group. A single individual could exist in four systems under three different names with two different email addresses and conflicting dates of birth. The commercial team could not answer basic questions: how many unique customers do we serve, what is the total revenue per customer across all divisions, which customers are at risk of churning?
A prior attempt to solve this had failed spectacularly. The company had licensed a master data management platform and attempted to build a golden record by importing all twelve systems into a central hub. The project ran for fourteen months, spent $2.3 million, and produced a golden record that matched eighty-two percent of customers. The remaining eighteen percent — roughly sixty thousand records — had conflicting data that the MDM platform could not resolve automatically. Manual resolution of sixty thousand records would have taken a team of twelve people approximately eight months. The project was abandoned.
Starting Without a Master Record
The second attempt began with a rejection of the golden record concept. Not because golden records are wrong in theory, but because the effort to create a perfect golden record across twelve systems with fifteen years of organic data quality problems was disproportionate to the value it would produce. The company did not need a perfect record. The company needed to answer specific questions about its customers.
We reframed the problem. Instead of “unify all customer data into a single record,” the question became “given a set of business questions, what is the minimum integration that can answer them?”
The business questions were:
- What is the total revenue per customer across all divisions?
- Which customers are active in more than one division?
- Which high-value customers have not been contacted in ninety days?
- What is the customer churn rate by division and by product line?
Each question required a different subset of the customer data. Revenue questions needed billing system linkage, not CRM unification. Cross-division activity needed identity resolution, not schema harmonization. Contact recency needed the most recent interaction timestamp from any system. Churn rate needed a consistent definition of “active” across systems.
The Identity Resolution Layer
The core technical challenge was identity resolution: determining that a record in System A and a record in System B referred to the same person. The MDM approach tried to resolve all records upfront. Our approach resolved identities on demand, for the specific records that were relevant to each business question.
An identity resolution service was built that accepted a set of candidate records from any combination of systems and returned a confidence score for each pair. The matching logic used a weighted combination of signals: exact name match (high weight), email match (high weight), phone number match (medium weight), date of birth match (high weight), address match (low weight, because addresses change frequently in healthcare). The weights were tuned against a manually labeled sample of five thousand record pairs that a panel of three domain experts had classified as same-person, different-person, or ambiguous.
The service did not make binary match/no-match decisions. It returned a confidence score between zero and one. Records with a score above 0.85 were treated as matches. Records below 0.60 were treated as non-matches. Records between 0.60 and 0.85 were flagged for human review. This three-zone approach avoided the false precision of a binary threshold. The eighty-five percent threshold was chosen because the labeled sample showed that false positive rates below this threshold were under two percent, which was acceptable for revenue aggregation but not for compliance-sensitive decisions.
This diagram requires JavaScript.
Enable JavaScript in your browser to use this feature.
The identity resolution service was not a batch process. It ran as an API that was called when a business question required cross-system linkage. When the commercial team asked “what is the total revenue per customer,” the revenue aggregation service called the identity resolution service to link billing records across systems. The linkage was computed for the specific population relevant to the question, not for all records in all systems.
This on-demand approach had a significant advantage over upfront resolution: it was incremental. The first business question — total revenue — required linking billing systems, which involved approximately eighty thousand active customers. The identity resolution service processed these in forty minutes. The second question — cross-division activity — required linking CRM systems for the same population. The service reused the matches from the first question and computed new matches only for the CRM-specific records. Each subsequent question was faster because the match cache grew.
The View Layer
Business users did not interact with the identity resolution service. They interacted with views — materialized perspectives of customer data tailored to specific business questions.
The revenue view joined billing records across systems using identity resolution matches and presented a single row per customer with revenue totals by division, by product, and by time period. The view did not attempt to reconcile customer names, addresses, or contact information. It showed the customer’s identity as it appeared in the system with the most recent update, with a link to the source record in each system.
The activity view combined interaction timestamps from all CRM systems and presented the most recent touchpoint per customer, the number of days since last contact, and the responsible sales representative. When the same individual appeared in multiple systems with different sales representatives, the view showed all representatives, which occasionally surfaced territory conflicts that had been invisible before.
The at-risk view applied the churn definition — no interaction in ninety days for standard customers, sixty days for enterprise customers — against the activity view and filtered to customers above a revenue threshold. This view was the one that produced immediate action. The first time the commercial team saw the at-risk view, they identified forty-seven enterprise customers who had not been contacted in over sixty days. Fourteen of those customers had open support tickets in a system that the sales team did not monitor. The tickets had been open for weeks without a follow-up call.
What the On-Demand Approach Cost
The on-demand resolution approach traded upfront completeness for query-time latency and coverage gaps.
Not all records were resolved. The match cache contained only the records that had been involved in a business question. Records that had never appeared in a query — inactive customers, historical records from decommissioned products — were unresolved. If a new business question required linking those records, the resolution service would compute matches at query time. This was acceptable for current business questions but meant that historical analysis could not be performed instantly. The team learned to pre-warm the cache for planned analyses by running the resolution service against the relevant population the night before.
The human review queue accumulated records that the service could not confidently match or reject. Over six months, the queue grew to eleven thousand record pairs. The company assigned two data stewards to review the queue at a rate of approximately sixty pairs per day. The review process was straightforward for the stewards — they had domain knowledge that the matching algorithm lacked — but the queue never reached zero because new records were continuously added. The team accepted this as a permanent operational cost rather than a problem to be solved.
Conflicting data across systems was never fully resolved. When System A said a customer’s primary phone number was 555-0101 and System B said it was 555-0102, the identity resolution service correctly identified the records as the same person but could not determine which phone number was correct. The view layer showed both numbers with their source systems. The commercial team made their own judgment. This was a feature, not a bug — it surfaced data quality issues that had been hidden by the fragmented system architecture.
The Result
After eight months, the company could answer all four business questions that had been previously unanswerable. Total revenue per customer was available within two hours of a query. Cross-division activity was visible for the first time, revealing that twelve percent of enterprise customers used three or more divisions — a segment that had been invisible because each division tracked its own customers independently. The at-risk view produced a weekly action list that the commercial team used for outreach. Churn rate by division was reported quarterly with a consistent definition for the first time in the company’s history.
The project cost was $480,000 over eight months — one-fifth of the failed MDM project — and did not require migrating or decommissioning any of the twelve CRM systems. The systems remained in place. The identity resolution layer sat on top of them. When a division eventually migrated to a common CRM, the resolution service adapted by adding the new system as a source and removing the old one. The layer was migration-agnostic.
The Heuristic
Before unifying data across multiple systems, list the questions you need to answer. For each question, identify the minimum data elements required. If the minimum is three fields from two systems, do not harmonize all forty fields from all twelve systems. Build the resolution layer for the questions, not for the data.
Golden records are a means, not an end. The end is answering business questions. If you can answer the questions without a golden record, skip the golden record. You can always build one later if the questions demand it. You cannot unspend the fourteen months and $2.3 million that a premature golden record project consumes.
