Duplicate Contacts, Conflicting Consent, and a Product Launch Deadline

Prioritize by risk, not by record count. First freeze new list imports and build a duplicate report keyed on normalized email plus company domain. Classify duplicates into four buckets: no deal association and no consent conflict; open deal or opportunity association; consent conflict; and role-based or shared inboxes.

• Bulk-merge first: the no-deal, no-consent-conflict records. These are large in volume and low in risk. Back up properties first.
• Manual review second: records attached to open deals. Use the record with the open deal as the survivor, but map the losing record's verified phone, title, and company into it before merging. Do not let the older record win by default.
• Consent conflicts: never merge opt-out into opt-in without preserving the most restrictive consent where required. Keep a consent property with source, timestamp, and audit note.
• Role-based emails: do not merge into a person. Convert to a company record or mark as non-marketing.

Field survivorship should be explicit: most recent verified email and phone; owner from the deal-associated record; lifecycle stage only when evidence supports it; company properties from the most complete source. This week, merge the low-risk bucket; queue deal and consent cases for review. That protects sales associations while still giving launch segmentation a cleaner base.

The root problem is that both systems are allowed to write lifecycle stage and consent without rules. Define stage meaning by evidence, not by form fill.

A workable model is:

• Subscriber: explicit opt-in, no sales qualification.
• Lead: known contact with fit data or meaningful engagement, but not sales-ready.
• MQL: meets fit criteria plus an intent threshold, for example a demo request, pricing-page visit combined with a webinar, or a high-intent content download. A single email open must never create an MQL.
• SQL: sales has accepted and completed a qualification call. This is a sales-owned stage.
• Opportunity and Customer: tied to the deal record, not manually overwritten by marketing imports.

Assign system of record: Salesforce owns owner and opportunity association; HubSpot owns marketing consent and engagement history. If a sync rule would overwrite consent, block it. Regional teams can vary qualification questions, but not the definition of MQL or SQL. Add required properties for stage changes and consent source. For the launch, build segmentation on firmographics, product usage, and role, then exclude unsubscribed and ineligible records. Without this governance, deduplication will be undone by the next import.

Prevention has to sit at the point of creation and at the point of import. First, standardize contact creation: forms should use hidden fields for campaign and source, require country, and use progressive profiling instead of asking for everything at once. Set a unique identifier policy based on normalized email plus company domain, with a manual exception path for legal or shared inboxes.

Second, create an import checklist. Every list import must be staged, deduplicated against existing records, mapped to approved properties, and reviewed by operations. No sales team should import directly into the live database. One-off imports are the likely source of the Opportunity-stage conflicts, so remove that permission or require a workflow.

Third, build monitoring. A weekly data-quality dashboard should track duplicate rate, missing country, consent conflicts, records without an owner, and lifecycle-stage regressions. Set alerts when duplicate creation rises after a campaign.

Finally, make launch segmentation reproducible. Use active lists built from governed properties, not manually uploaded CSVs. Document the inclusion and exclusion rules for each segment, including consent and customer status. This gives leadership a repeatable launch process and reduces the chance that the next campaign recreates the same mess.