Philippines CRM duplicate-record merge review: preserve identity, history, and consent

A duplicate score is only an invitation to inspect

Two records named Ana Reyes share a mobile number but have different email addresses, account owners, and marketing permissions. An automated rule assigns a 94 percent duplicate score. Merging immediately could combine two relatives, erase a valid opt-out, move an opportunity, and expose one person’s notes to another.

The reviewer first states why the pair entered the queue: exact normalized phone, similar name, matching external identifier, or a user report. Each signal has a known weakness. Shared household numbers, recycled addresses, aliases, typographical corrections, and business contacts all produce plausible false matches.

Define three outcomes: confirmed same subject, confirmed different subjects, and unresolved. Only the first proceeds to a merge plan.

The NIST Privacy Framework is helpful because it frames data processing around risk and traceability, not merely database cleanliness. The client remains responsible for the purpose and rules of its customer data; a Philippines-based specialist applies those rules to bounded candidates rather than making broad identity policy from intuition.

Compare identifiers by origin and time

Create a side-by-side worksheet for stable identifiers, contact points, organization, geography, lifecycle stage, account ownership, activity history, linked objects, privacy status, and integrations. For each value, show where it came from, when it was captured, and whether the source was verified. The same email copied by a sales representative is weaker than an address confirmed through the product.

A changed surname is not a conflict until the history is understood. For Ana’s pair, the phone may have been entered by a partner on one record and verified by Ana on the other. That distinction matters.

Never paste sensitive notes into an ungoverned spreadsheet just to make comparison easier. Use approved fields or a case view with least-privilege access.

Look for evidence that records were previously split, merged, imported, or synchronized, because the apparent duplicate may be the symptom of a mapping defect. Record unknowns explicitly; blank fields do not support a match and should not be treated as agreement.

Design survivorship before touching production

Once identity is confirmed, decide what the resulting record should contain. Survivorship is not “keep the newest. ” The verified contact point may outrank a recent unverified import; the active contract owner may outrank an outdated territory assignment; the most restrictive valid communication preference may require special handling.

Define a rule for every consequential field and linked object. Activities usually need consolidation without changing authors or timestamps. Opportunities, cases, invoices, entitlements, attachments, campaign membership, and product identities may have separate owners and cannot always be reparented safely.

Preserve original record IDs and a snapshot so downstream teams can trace references. In the Ana scenario, one profile contains the current account relationship while the other contains a do-not-contact instruction.

The client privacy owner determines how the instruction applies; the merge operator must not discard it because the other record is “primary. ” A dry-run output should list every selected value, moved relationship, retained conflict, and integration expected to update.

Use a reversible execution window

Schedule merges when integration owners can observe them. Before execution, confirm the pair has not changed since review, capture exports or approved recovery evidence, and obtain approval tied to the exact IDs. Use a named CRM account and the narrowest merge permission.

After execution, inspect the surviving record, activity ordering, ownership, privacy fields, linked cases, and search results. Then check important downstream systems: marketing automation, support, billing, analytics, and identity services may each consume different keys. A CRM success message proves only that one application accepted the action.

If the merge cannot be reversed natively, the runbook should describe reconstruction and who may authorize it. Stop a batch after the first unexpected integration result. Do not continue because the remaining pairs “look the same.

” For higher-volume work, cap each execution window and reconcile all cases before opening another. This limits the blast radius and gives the process owner evidence about whether the candidate logic and survivorship rules behave as designed.

Handle the hard pair without forcing an answer

Return to Ana’s records. Suppose one email corresponds to a purchaser and the other to a product administrator at the same company; the phone is a shared reception line; notes casually shorten both names to Ana. The correct result may be two contacts linked to one account, not one person.

The reviewer marks the pair unresolved or distinct, states the disambiguating evidence needed, and suppresses repeated suggestions for a defined period. A customer-confirmation request may be appropriate, but only through an approved script that does not reveal the other record. Other escalation triggers include conflicting government or customer IDs, minors, protected attributes, active disputes, legal holds, and records belonging to different controllers or regions.

The client data steward decides. This “do not merge” discipline is useful work: it prevents destructive certainty and improves future matching rules. Track why false positives occur, such as shared phones or truncated imports, so the data team can tune candidate generation rather than paying reviewers to reject the same pattern indefinitely.

Judge the program by recoverability and error prevention

Operational reporting should separate candidates reviewed, confirmed merges, distinct pairs, unresolved pairs, stale candidates, failed executions, downstream exceptions, and reversals. Sample all outcomes, not just completed merges. Verify that the evidence supports the identity decision, approvals match IDs, sensitive data stayed in approved tools, and important fields survived according to rule.

Measure aging by blocker so a delayed data-owner decision is not mislabeled as reviewer inactivity. Audit a small set after several days to catch integration lag.

A useful pilot starts with one source and low-risk contact records, excludes records with financial or sensitive consequences, and adds complexity only after recovery is proven. The reader’s outcome is a merge lane that improves usability without sacrificing provenance: reviewers can explain why two records were joined, reconstruct what changed, protect conflicting preferences, and leave uncertain people separate until an accountable owner has adequate evidence.