A merged customer record needs a survivorship contract

Intercom's September 28 product update makes profile merging more practical: an operator can merge a duplicate from the conversation sidebar, preview what will move, control access with a teammate permission and, for developers, use a REST API in Preview. This is good product design because it adds visibility and authority around an identity operation. It also makes a missing organizational control more obvious. A preview can show the proposed movement of records, but it cannot decide which customer identity should survive for the business.

That decision belongs in a survivorship contract. The contract is a short, reviewable policy that defines how a team chooses the surviving profile, handles conflicting attributes, preserves source lineage, evaluates account associations and checks downstream systems. Without it, every merge becomes a local judgment. A support operator may prioritize conversation history, a CRM administrator may prioritize the sales record and a lifecycle team may prioritize the address with the most recent consent. Each choice can be defensible while still producing an inconsistent customer model.

The first rule should be that no mutable label wins automatically. Names change, email addresses change, people move employers and shared inboxes represent multiple people. Even a current work email does not prove which profile owns historic tickets, product usage or consent. Prefer durable source identifiers and explicit associations. When those conflict, preserve the conflict as an exception. Data quality improves when the system can say that identity is unresolved; it degrades when uncertainty is hidden inside a confident merge.

The second rule should distinguish profile survival from field authority. The surviving Intercom user record may be the place where conversations are consolidated, while the CRM remains authoritative for account ownership and the billing platform remains authoritative for subscription status. A merge should not silently crown one platform as the owner of every attribute. The contract lists fields or field groups, the current source of truth and the behavior when two sources disagree.

The third rule is to preserve history at the level needed for reconstruction. The business does not need to retain every duplicate forever in every interface. It does need enough evidence to answer which records were combined, who or what approved the change, which values were selected and which downstream actions occurred afterward. That evidence matters when a customer disputes a communication, an account is assigned incorrectly or an automation appears to have skipped a suppression.

API access raises the standard. Manual merging is slow enough that an operator naturally inspects many cases. An API can convert a matching rule into thousands of identity changes. Preview status is a reminder that the endpoint and its operational behavior should be tested in the target account. The job needs an approval boundary, idempotency key, stable pair identifiers, rate and batch controls, dry-run output, exception queue and independent verification. Convenience is not the same as safety.

The fourth rule is that downstream customer actions do not inherit merge approval automatically. Combining duplicate profiles may be justified while launching a campaign, changing a renewal owner or applying a service entitlement still requires a current business-state check. Put high-impact automations behind a short hold or a post-merge flag. Release them only after the surviving record has the expected account, preference, lifecycle and contractual associations.

Amplitude's September 23 survey change illustrates why. Analysts can now export survey responses with selected user properties in the same CSV. That reduces manual work, but it also makes the current profile context more portable. If a merge selected the wrong account or plan property, the error can flow into a research file without an obvious join step where someone might notice it. The export process should record the selected fields, access policy, extraction time and analysis grain.

Hightouch's September changelog adds another reason for caution. Audience memberships can appear as a trait and synchronize to destinations. Membership is computed context, not a permanent identity attribute. After a merge, the surviving person may enter or leave audiences as definitions are re-evaluated. The survivorship contract should name which derived fields must be recomputed rather than copied and which outbound syncs need a reconciliation run.

Some teams resist a formal contract because duplicate repair feels like cleanup that should happen quickly. The opposite is true. A clear policy speeds routine cases because operators do not have to reinvent the decision. It also makes the hard cases visible earlier. The contract can be a page, not a committee: approved identifiers, forbidden automatic conflicts, source authority, merge permission, evidence retention, downstream hold and rollback owner.

The weekly operating review should include more than the number of duplicates removed. Sample merged pairs, inspect the reasons they matched, confirm destination records and review any downstream exceptions. Track repeated causes such as form behavior, integration mapping, anonymous-to-known conversion or inconsistent account creation. A good merge program shrinks the upstream sources of duplication instead of building an ever-faster repair machine.

The contract should also distinguish an identity merge from an employer change. Two profiles can belong to the same human while representing different account relationships that must not be collapsed for revenue reporting, consent or access. Preserve the valid-time association between person and account, and let the business decide which histories may coexist on one profile without rewriting the commercial past.

Finally, publish the stop rules. Shared inboxes, conflicting external IDs, incompatible consent evidence, two active product tenants or unresolved legal and billing identities should block automatic consolidation. A visible stop rule protects operators from pressure to make the duplicate count look better and gives upstream teams concrete defects to fix.

A customer record is not cleaner merely because there is one of it. It is cleaner when the surviving identity is explainable, the consolidated evidence is traceable and downstream teams can rely on its current associations. Intercom's new controls make the mechanics safer. RevOps must supply the business policy that turns those mechanics into trustworthy operations.

Related reading: Data Quality · Customer Success · Lifecycle Marketing · Intercom