The Orphaned-Lead Backlog Teardown: Domain Pass to Audited Write-Back

This guide clears a backlog of leads with no account attached. Each lead ends up either on the right existing account or deliberately unattached, with a decision code and the evidence behind it. It is for the RevOps or recruiting-ops owner who will be asked later why a lead went where it went. I follow one 3,000-lead queue through every pass, including the two wrong turns the audit caught, and finish with a coverage and precision report you can sign off before anything writes to the CRM.

What are the published lead-to-account match rates worth?

As targets, almost nothing. The most-repeated split is roughly 70% matched on email domain plus another 15-20% on fuzzy company name. It is quoted without a source, without a denominator, and without any statement of how correctness was checked.

The rest of what ranks for "how to match leads to accounts" has the same gap:

• A glossary page puts exact-match rules at 50-70% and fuzzy logic at 70-90%, with no method.
• Vendor claims run from 94% on a first run up to 99.7%. None publishes a method.
• The only segment claim is that for local or SMB selling, email-domain matching produces structurally lower match rates. No source splits enterprise and SMB by pass.
• No one publishes the share of a queue that resolves through alias or regional domains, or the share that can never be resolved.

The missing denominator is the real problem. "70% matched on domain" means one thing as a share of all leads and something else as a share of leads that had a corporate address to begin with. So I define two numbers before every run and report both:

• Coverage is the share of leads in the batch that end up attached to an account. It shows how much got attached. It misleads when a loose pass, usually fuzzy name matching, attaches leads to the wrong firm and still counts them.
• Audited precision is the share of attachments a reviewer confirms are correct. It is estimated from a random sample and carries a margin of error. It shows how much is right. It misleads when one sample covers the whole batch and the easy exact-domain hits drown out errors in the harder passes.

A match rate without a denominator and an audit is a sales claim, not a measurement.

What does the CRM do to an unmatched lead on its own?

Native matching works from the email domain, which means it attaches too little and attaches wrongly at the same time. HubSpot gives each subdomain its own company record and, when several companies share a domain, attaches a contact to only one of them. Salesforce matching rules flag likely matches but do not create the relationship.

Learn these behaviours before the first pass, because some of them act on your backlog whether you run anything or not.

The Salesforce rows decide how you write back, so here is the detail:

• Lead-to-account matching uses the Standard Matching Rule for Leads on Accounts. One secondary source says it needs Account Engagement Advanced or Premium. Match keys narrow the comparison to the 100 most likely duplicates. You get up to five active matching rules per object and three per duplicate rule.
• Lead assignment rules run only when the AssignmentRuleHeader is set on the create() or update() call. The AssignmentRuleHeader is an API flag that tells Salesforce to apply assignment rules to the records in that call. An update carrying useDefaultRule=true re-runs assignment.
• When an account's owner changes, Salesforce automatically moves the contacts and open opportunities owned by the previous owner. An opportunity owner change that cascades this way does not invoke flows or Apex triggers. Workflow rules that update owners do not transfer associated items.
• An older blog reports that changing an account owner through the API or Data Loader changes only the account owner. That is unverified for current releases, so test it in a sandbox before you rely on it.

HubSpot also advises against turning on auto-association alongside the Salesforce integration, because it can create duplicate company records. Dynamics 365 behaviour is not established in my research. If you run it, test association and ownership behaviour in a sandbox with a handful of leads before the batch.

The matching procedure: nine steps from freeze to write-back

The procedure has six parts: freeze automation, normalize, run the matching passes from most to least certain (resolving multi-matches along the way), send name-only candidates to review, audit, and write back with a log. Each pass sees only the leads earlier passes left unresolved, so every attachment traces to exactly one pass and one decision code.

Sources disagree on the order in two places. One glossary puts a company-identifier match second, ahead of name. LeanData says domain alone is not typically enough to form a match unless configured. Either way, I keep name-only matching last. It carries the highest false-positive risk, so it should only ever see leads that every other pass rejected.

Who should review the forks?

The forks need someone who has built lead matching or routing before, and that person is hard to find. In Refolk's index of professional profiles, only 8 of 1,053 US Revenue Operations Managers list LeanData as a skill.

Two things follow for this job:

• The method has to be tool-neutral. Hardly anyone in the pool lists experience with the dedicated matching tool, so the decision codes, log, and audit here work the same on native rules or a script. Skill tags are self-reported and probably understate real usage, though that is unverified. Treat 8 as a floor, not a count.
• UK expertise is concentrated in one city. The UK pool is about a fifth the size of the US pool, and nearly half of the sampled UK profiles sit in London. The US sample is spread out, with New York holding only 3 of 25.

I staff the review this way. The person who ran the passes does not review them. One reviewer owns the multi-match and name-only strata. The owner of any open opportunity signs off on attachments that touch that opportunity. When I need an outside reviewer, I describe the experience to Refolk in plain English rather than filtering on a skill tag that fewer than 1% of the pool filled in.

The worked backlog: 3,000 orphaned leads, fork by fork

The worked queue is 3,000 leads with no account, cleared in the pass order above. On the first run, two passes went wrong: a fuzzy name pass attached leads to look-alike firms, and a parent-first tiebreaker hid a live opportunity at a subsidiary. The stratified audit caught both before anything wrote back.

I am not printing this queue's pass shares as a benchmark. A split from one queue mostly reflects its channel mix, as the normalize step shows. The numbers below are the ones you can compute in advance. Your own pass counts go in the log.

Freeze and snapshot

Auto-association went off, and the integration user's writes were confirmed to carry no assignment header. All 3,000 rows were snapshotted with lead ID, current account (blank for every row) and current owner. That snapshot is the "before" column of the log. It is the only reliable record of ownership, because cascaded owner changes skip the triggers that most audit logging depends on.

Normalize: how much of the queue is freemail?

Freemail means a consumer email domain, such as a webmail provider, that says nothing about the employer. How much of a queue is freemail depends on the channel more than anything else.

• Content syndication: 55% personal email.
• Website forms (older test): 6% in the USA, 5% in the UK, 9% in Australia.
• By company size, individual contributors at companies under 100 employees used personal email 69% of the time. At companies over 5,000 employees it was 49%.

For a 3,000-lead batch, that means roughly 1,650 freemail leads if the batch is all syndication, and roughly 150 to 270 if it is all website forms. That one fact decides whether recovery is a footnote or most of the job, so tag the source before you plan reviewer time. Fixing the problem at the form has a cost too: one study reports that requiring a business email cut form conversion by an average of 52%.

Strip subdomains in this step. In HubSpot, @example.com and @info.example.com result in two different company records. Tag anything you cannot parse as malformed and give it a code. Do not drop it.

Exact domain pass

Before running the match, count the accounts per domain. This count is where shared domains show up. If you skip it, a domain that maps to a parent and two subsidiaries looks like a clean single hit.

• Exactly one account: decision code D1, auto candidate.
• More than one account: goes to the multi-match queue.
• No account: goes on to the alias pass.

Alias and regional domain pass

An alias domain is another domain the same organization uses, such as a regional or legacy one, mapped to an existing account in a table the admin maintains. Matches here get code D2. An alias entry is only as trustworthy as the person who added it, so the table records who added each entry and when.

Personal-email recovery

The fields that can recover an account are the submitted website, company name, phone, and address. HubSpot falls back to Website URL. LeanData uses close name plus phone or address, and does not match on free domains at all. No one publishes how often each field recovers an account, so count your own hits per field.

I attach only when two fields agree, under code R1. Sometimes all a freemail lead has is a name and a claimed employer. Then I look the person up in Refolk to check the current employer on their public profiles. That counts as one evidence field, never two. Leads with no agreeing evidence get code U2 and stay unattached.

Multi-match resolution: the parent-first wrong turn

Some teams default to parent accounts, and LeanData documents this as an option. The first run used it. Leads on a domain shared by a parent and its subsidiary went to the parent, including leads from a subsidiary that had a live open opportunity. Those leads would have routed to the parent's owner and never reached the person working the deal. The audit of the multi-match stratum caught it.

The fix is an order of operations: check every candidate account for an open opportunity before any hierarchy rule applies. After that, the documented tiebreakers are account status, region, and recency. Examples include same-region owner, most recent activity, and oldest created date. Using an acquisition's effective date as a tiebreaker is not established publicly. Neither are rules for when to abstain, so the one below is mine.

Name-only candidates: the fuzzy wrong turn

The first run let fuzzy name matching auto-attach above a score threshold. The commonly cited thresholds are above 90% for auto-attach and 70-90% for human review. Native rules over-match common names, and this run attached leads to unrelated look-alike firms. Coverage went up, which is exactly how coverage misleads. The errors surfaced only because name-only attachments were audited as their own stratum.

The decision codes and the log

Every lead gets exactly one code. There is no published standard for these codes; this set is mine, and it maps directly to the passes.

lead_id,email_domain,domain_class,pass,decision_code,chosen_account_id,candidate_account_ids,evidence_fields,tiebreaker_used,open_opp_check,reviewer,account_before,owner_before,account_after,owner_after,notes
L-0001,example.com,corporate,exact_domain,D1,ACC-0001,ACC-0001,email_domain=account_domain,none,no_open_opp,,,OWNER-A,ACC-0001,OWNER-A,

How does lead-to-account matching go wrong?

Seven failure modes account for most bad attachments. Most produce attachments that look correct in the CRM and only show up later in routing or in an audit.

1. Fuzzy name pass attaches leads to look-alike firms. Looks like: coverage rises and every attachment looks plausible. Check: audit name-only attachments as a separate stratum, and require phone or domain to agree.
2. Shared domain silently picks one account. Looks like: a clean single match, often a parent chosen over the live subsidiary. Check: count accounts per domain before the exact domain pass.
3. Parent-first tiebreaker hides an open opportunity at a subsidiary. Looks like: a tidy hierarchy and a deal owner who never sees the lead. Check: run the open-opportunity check across every candidate before applying the parent rule.
4. Write-back fires assignment or ownership changes. Looks like: owners changing on records you never touched. An update carrying useDefaultRule=true re-runs assignment, and a cascade moves contacts and opportunities without leaving an automation trail. Check: diff owner fields before and after on a pilot batch.
5. Auto-association reattaches the backlog behind your back. Looks like: leads acquiring companies that no pass assigned. Check: confirm HubSpot's setting is off before step 3.
6. Precision measured on the easy stratum only. Looks like: a high precision figure from one batch-wide sample. Check: sample each pass separately.
7. Report field disagrees with routing. Looks like: coverage in the report that routing does not honour. LeanData's Reporting Matched Account field and its routing node have separate filters and tiebreakers, so they can return different accounts. Check: reconcile the two before reporting coverage.

Volume makes all of these worse. As one source puts it, even a 5% false positive rate compounds into real routing errors at volume. On this batch, 5% is about 150 misrouted leads.

How big should the audit be, and what goes in the report?

Size each stratum's sample with Cochran's formula plus finite population correction. For a 3,000-lead batch at 95% confidence, a conservative plus or minus 5% margin needs 342 audited leads. A stratum is the set of leads one pass attached, audited as its own population.

Cochran's formula is n = (Z² × p × (1 − p)) / E². Here p is the precision you expect, E is the margin, and Z is set by the confidence level. Finite population correction then shrinks n when the population is small. Computed for this batch:

Halving the margin roughly quadruples the sample, because n scales with 1/E². Tightening the whole batch from 342 to 788 mostly buys more reviews of exact-domain hits, which were never the risk. Put the effort into the multi-match and name-only strata instead. A smaller stratum needs a smaller corrected sample. In a worked example with N=1,000, an n of 385 adjusts to roughly 278.

No published source gives an acceptable false-attachment rate for a bulk write-back. Set yours before the audit, write it in the report, and do not move it after you see the results.

Batch ID:
Leads in batch (N):
Coverage denominator: all leads / corporate-domain leads only
Coverage: attached / denominator =
Attached by code: D1 = | D2 = | R1 = | M1 = | N1 =
Unattached by code: U1 = | U2 = | U3 =
Freemail share and dominant source channel:
Audit confidence level: 95%
Per stratum: sample size | margin | confirmed / sampled | precision
Acceptable false-attachment threshold (set before audit):
Strata above threshold and action taken:
Report field reconciled with routing: yes / no, differences:
Pilot write-back: unexpected owner changes =
Reviewer(s):
Sign-off:

How do you write back without untraceable ownership changes?

Write back through the API with the assignment rule header off, run a pilot batch first, and diff every owner field before and after. Keep the before and after values in your own log outside the CRM, because cascaded opportunity owner changes do not fire flows or Apex.

The pilot is the cheapest test you will run. Write a small slice from each code and pull the owner fields on the leads, their accounts, and those accounts' contacts and opportunities. If any owner changed that your log did not predict, stop, find the cause (an assignment header, a workflow, a cascade), and fix it before the full batch.

To keep the queue from refilling unnoticed:

• Run new orphans through the same passes and codes, so batches stay comparable.
• Keep the alias table current, with author and date on every entry.
• Re-check the freeze settings whenever someone changes the CRM integration, since auto-association acts retroactively.
• Re-tag the source channel each batch, because the freemail share and the recovery workload move with it.