We reviewed the full 3-part CSV export of the Unicity contact base ahead of the bulk import into Intercom. The base is in strong shape overall — most of what needs attention falls into a small number of well-understood buckets, and EscalateOps can resolve the majority of it without any further input from Unicity.
| Category | Records | % of total | Who resolves it |
|---|---|---|---|
| Clean & ready to port | 174,043 | 95.5% | Nothing to do |
| Duplicate — same person, re-registered | 5,766 | 3.2% | EscalateOps (auto) |
| Duplicate — shared email, different people | 1,941 | 1.1% | Needs Unicity decision |
| Duplicate — same person across file parts | 369 | 0.2% | EscalateOps (auto) |
| Malformed email | 32 | 0.02% | Needs manual review |
8,076 rows (4.4% of the base) share an email address with at least one other record. These break down into three distinct patterns, each with a different cause and a different resolution path.
Same name, same email, different Customer ID — matches what Nilesh estimated on the call ("~2,000-ish cases"). Root cause, per Matthew: a known MLM pattern — a customer or their upline re-registering, or accounts managed by an upline for distributors without their own email, before Unicity's current policy discouraged the practice.
EscalateOps will resolve this automatically — keep the most recent Customer ID per group. No input needed from Unicity.
Different names sharing one email — couples, family members, or an upline managing multiple downline accounts. These cannot be safely auto-merged: collapsing them risks mixing two different people's data under one Intercom profile.
Recommendation: when Fin cannot uniquely resolve which person is writing in, escalate directly to a live agent rather than guessing. Open question: is there a secondary identifier (e.g. Distributor ID) we should ask for in these specific cases to disambiguate, similar to what's used for frictionless login today?
Same name and email appearing in more than one of the 3 CSV parts — likely an artifact of how the export was chunked, not a data entry issue.
EscalateOps will de-duplicate these the same way as 1a.
A small number of records (0.02%) have an email that isn't usable as-is — missing the "@", or a phone number entered directly into the email field.
Confirmed by Matthew: these originate from the legacy system currently being phased out, which doesn't enforce email validation on entry (unlike the current frontend, which does). Since that system is being decommissioned in the next 1–2 months, this issue should stop growing — it only needs a one-time manual review of the existing 32 records.
| Status | Records | % of total |
|---|---|---|
| Already has full country code (just needs '+' added) | 130,033 | 71.4% |
| National number, recoverable using country field | 24,078 | 13.2% |
| No phone number on file | 23,634 | 13.0% |
| Invalid / unrecoverable | 4,406 | 2.4% |
84.6% of phone numbers can be normalized to valid WhatsApp (E.164) format automatically. Fully handled on EscalateOps' side — no action needed from Unicity.