When we merge two duplicate customer records, how do we decide which values to keep?

Most merge tools ask the wrong question

The typical merge screen asks you to pick a master record and discard the other. That is the wrong unit of decision. In practice the newer record usually has the better phone number and the correct spelling of the name, while the older record holds the original lead source, the first job date and the campaign that produced the customer in the first place. Choose either record whole and you lose half of what you needed.

Field-level survivorship fixes this. You keep the surviving record's identifier so nothing downstream breaks, then resolve each field independently according to a rule you wrote down in advance.

Four classes of field, four rules

Almost every field in a customer record falls into one of these buckets.

• Recency wins. Phone, email, mailing address, preferred contact method. The most recently confirmed value is the most likely to still be true.
• Earliest wins. Original lead source, first campaign, created date, first job date. These are historical facts and must never be overwritten by the newer record's defaults, which is exactly what a naive merge does.
• Union. Jobs, invoices, estimates, calls, notes, attachments, equipment. Nothing in this class should ever be discarded; every child record moves to the surviving parent.
• Most restrictive wins. Do-not-contact, credit hold, tax exemption, litigation or complaint flags. If either record says stop, the merged record says stop. This is the rule people most often get backwards, because recency looks like the obvious default.

A merge you cannot undo is a merge you should not run

False merges happen. Two households at the same duplex, a father and son with the same name, a property manager's number on two unrelated accounts. If you cannot reconstruct what the records looked like before, a bad merge is permanent data loss.

Keep a merge log with the surviving identifier, the absorbed identifier, and the before and after value of every field that changed. That log is also what lets you re-run a corrected rule later without guessing. This kind of bookkeeping is unglamorous, and it is most of what real data integration work consists of.

Merges ripple outward

The absorbed identifier does not disappear from the rest of your stack. Marketing platforms, call tracking, review requests and any reporting warehouse may still hold it. Publish merges as events other systems can consume rather than expecting them to notice, or you will spend months chasing records that point at an identifier that no longer exists. Keeping those identity relationships coherent across systems is the core of customer intelligence that people actually trust.