Stitching one customer identity across a product database, a CRM and two billing systems

The problem

The play

1. 1
   Measure the linkage before designing anything

   The first deliverable was a coverage audit across the foundational systems expressed as blunt percentages, not as a maturity opinion. Person-level identity, product user to CRM contact, was effectively solved.

2. 2
   Deterministic tiers first, fuzzy later

   A tiered match ladder: exact ID match, exact email match, normalized or fuzzy email, company domain plus name heuristic, and a manual review queue as the terminal tier. Phase one shipped only the deterministic tiers, so every match in production could be explained to a sceptical finance stakeholder in one sentence.

3. 3
   Domain matching, with the exclusion list as the load-bearing part

   Deriving the email domain from billing invoices and matching it against product user email domains recovered a large slice of the unmatched population. The exclusion list is what makes this safe rather than catastrophic: free and consumer mail providers and the company's own internal domains are stripped up front.

4. 4
   Classify matches as unambiguous versus ambiguous instead of forcing a verdict

   Where a domain maps to exactly one organization, the match is unambiguous and auto-accepted. Where it maps to more than one, it goes into an ambiguous bucket for human confirmation rather than being resolved by a tiebreak rule.

5. 5
   Build the method to outlive any one billing vendor

   The same stitch had to be rebuilt against a second billing system, which would have orphaned the work if the method had been built around one vendor's schema. Because it was not, the rebuild took days.

6. 6
   Build the pipeline for change, not for snapshots

   Billing data landed first as a bulk snapshot load to unblock analysis, then moved to a change-data-capture pipeline for incremental ingestion. The warehouse model was kept in star schema so the new source slotted into the existing semantic layer rather than forking it, the migration added a source, not a second data model.

7. 7
   Argue for a match-rate tolerance before arguing about technique

   The most important intervention on this project was commercial rather than technical. Nobody had agreed what error rate was acceptable, which means 'improve the matching' has no finish line and the person consuming the number can reject it at any accuracy.

What it moved

From a LeanScale case studyRead the full case study →