Skip to content

Data & Intelligence

Data unification: one customer, one record, a rule for every match

The same customer is “Lakeview HOA” in the CRM, “Lakeview Homeowners Assn” in scheduling and “Lakeview Homeowners Association Inc.” in accounting. Until those are one record, every count is off. Data unification matches records across systems by rules you can read, decides which system wins for each field, and sends the uncertain matches to a person instead of guessing. We write the matching rules with you, so you can read every decision.
Talk through your dataSee the match rules ↓
CRMLakeview HOA555-0182 · board@lakeview.exampleSchedulingLakeview Homeowners Assn555-0182 · 40 Lakeview DrAccountingLakeview Homeowners Association Inc.40 Lakeview DriveCRMLakeview Dental555-0137 · 40 Lakeview Dr, Suite 2same phone · strongsame address · mediumAccount AC-318NameLakeview HOACRMBilling nameLakeview Homeowners Assoc. Inc.accountingPhone555-0182schedulingService address40 Lakeview DrschedulingEmailboard@lakeview.exampleCRMLakeview Dental · address only · to review

Three systems, three versions of one customer

Every system you use creates its own customer records, typed by different people at different times. One customer becomes three, and two businesses in one building can become one. Counts, revenue per customer and anything you send them all inherit the mistake.

Data unification settles identity once, with rules you can read. Strong signals merge records, weak ones only support, uncertain cases go to a person, and each field comes from the system that's responsible for it.

Today, and with data unification

Today

  1. 01Each system has its own customer list.
  2. 02Duplicates are merged by hand, when someone notices.
  3. 03Reports count “customers” differently depending on the source.
  4. 04Nobody can say which system's phone number is right.

The same customer gets two reminders, and the report says you have more customers than you do.

With data unification

  1. 01Records are matched across systems by written rules.
  2. 02Confident matches merge into one record; uncertain ones go to review.
  3. 03Each field comes from the system that owns it.
  4. 04The original records stay linked, so every merge can be traced and undone.

One customer, counted once, with a reason for every match.

Match rules you can read

Strong signals merge. Weak ones only support a strong one.
Same account id already linkedDecisiveLinks made by mistake, kept forever
Same phone, normalisedStrongA building's main line shared by several businesses
Same emailStrongShared inboxes like office@, which count as weak
Same address, standardisedMediumSeveral businesses or tenants at one address
Similar nameWeakOnly ever supporting a stronger signal

Three outcomes

AC-318 · merged

records
CRM #8812, scheduling #S-4410, accounting #A-0907
matched on
phone (strong), address (medium)
name
Lakeview HOA, from the CRM
billing name
Lakeview Homeowners Association Inc., from accounting
sources kept
all three, linked to AC-318

Which system wins, field by field

One owner for each field, written down, so a merge never depends on which record was edited last.
Billing nameAccountingIt's what appears on invoices
PhoneThe most recent of CRM and schedulingPeople change numbers; both systems hear about it
Service addressSchedulingTechnicians confirm it on site
Marketing consentCRMWhere consent is recorded and changed

The parts it's built from

Each part is built and tested on its own, so you can start with one and add the rest.

  1. Collect

    Data Ingestion

    Customer records from every system.

  2. Standardise

    Data Transformation

    Phones, addresses and names in one format.

  3. Match and merge

    Data Modeling

    • standardised records
    • match rules
    • field owners

    uncertain match → review, never a guess

  4. Enrich

    Data Enrichment

    Facts added to the unified record, with sources.

Underneath every stepData Quality & ValidationChecks that catch a bad merge before it spreads.

What changes from one business to the next

EntitiesCustomers, properties, accounts or jobs, whichever you need settled
RulesWhich signals count, and how strongly
Field ownersWhich system wins for each field
ReviewWho reviews uncertain matches, and how fast

A common starting point is PostgreSQL for the unified records, SQL or dbt models for standardising and matching, and a small review screen for uncertain matches. These are starting candidates, not requirements.

Is data unification the right system?

Good fit

  • The same customers live in two or more systems.
  • Counts or revenue per customer differ by source.
  • You're planning reporting or a customer view that needs one record per customer.

Avoid when

  • One system already holds every customer, and duplicates are rare.
  • Records have no shared signals, such as phone, email or address, to match on.

How we'd approach it

Most of the early work is agreeing which records to match, the rules, which system owns each field and who reviews the uncertain matches.

  1. 01

    Understand

    As much as the problem needs

    We map how the work runs today: who does what, which systems hold the records, and where it breaks.

  2. 02

    Design

    Decided before it's built

    Ownership, rules, integrations and exceptions, agreed with you and written down with acceptance criteria.

  3. 03

    Build

    Connected to what you use

    We build the scoped system, connect it to the tools you already run, and test it on the cases that matter.

Related systems

The capabilities underneath

For your industry

Questions about data unification

Does it change our source systems?

Not by default. The unified record lives alongside them. Corrections can be sent back, field by field, where a system should be fixed too.

Can a merge be undone?

Yes. Source records stay linked, and every merge records the rule that made it.

How many go to review?

It depends on your data. We run the rules on a sample first and tune them until the review queue is something a person can keep up with.

Is this master data management?

It's the same idea, sized for a business that needs a handful of entities settled, not an enterprise programme.

Make every customer one record

Tell us which systems hold the same customers today. We'll show you how many duplicates there are and how they'd be matched.

Start a project