Lead list vs CRM: who the match misses

The match ran. It just looked for something this company did not have.

Why a checked list still emails the wrong person

An existing customer replies to a cold email. The list was matched against the CRM before the send, and the match did not fail. It searched for a marker this customer does not carry in the CRM. The damage lands on the relationship worth the most, and in the report it looks like a weak offer.

The reason sits in what a match actually does. It does not compare companies, it compares strings. Two rows count as the same company when a rule says they are equal. Someone chose that rule while building the pipeline, and whoever reads the report never sees that choice.

Our take: we build the match in stages, because one comparison rule cannot cover the cases where the same company appears under two addresses. That is not an edge case. It is the normal state of anything older than a rebrand.

Two neighbouring questions are covered elsewhere: the checks on the row itself and whether a CRM record proves a customer relationship. This article is the step before both: whether the record is found at all.

"Not in the CRM" is a statement about your match

The sentence sounds like a finding about the company. It is a finding about your own search. People hear "we do not know this company", while what was measured is "it was not among the things we looked for". Every company filed under a second address lives in that gap.

So the sentence may only be said once all four keys have missed. Before that it is a guess with permission to send. The order is not arbitrary: it runs from the most conclusive marker to the weakest, and it also decides which hit is allowed to suppress a row on its own.

The outcome is a question you can put to your team or your agency: in what order do we match, and which of these keys suppress a row automatically? If nobody can answer that, nobody knows the state of the list.

A company's domain lives in two places

Your list holds the company's web address. The contact rows beneath it hold email addresses, and those carry a domain too. Usually the two agree. Where they do not, a company slips past suppression — and that happens disproportionately to the companies with history behind them.

Here is how it happens. A company registered a spelled-out domain years ago and sends mail from a short one today. The CRM holds the old address, your enriched list holds the new one. With invented examples: the CRM says example-architects.ch, the list says exa.ch. No comparison on the web address will ever connect the two.

Our take: we union both domain sources before comparing. Collect every domain attached to a row first, then search. A subdomain is reduced to its registrable form so that mail.example.ch and example.ch produce one key.

Two kinds of address yield no usable key at all: website builders and platform hosts, where many companies share one domain, and a profile page standing in for a website. On a multi-tenant host the tenant part is the key, never the platform. When the address field holds no domain of its own, the row runs on the name alone — the weakest key there is.

When a hit may suppress, and when it may only flag

A rule that allows similarity takes too much with it when in doubt. The list then shrinks quietly, and nobody sees which companies disappeared. That damage is harder to notice than the opposite one, because a list that is too short never triggers a complaint. It just books fewer meetings.

Our take: only a conclusive hit suppresses automatically. Anything interpreted gets flagged with a proposed way to verify it. Conclusive means the same record ID, the same registrable domain, or the same person under the same domain. None of those leaves room for reading.

Interpreted means the cases a string comparison can never see. One company contracts its name in the domain. Another uses its founders' initials. A third runs its website under a person's name. Each of those hits gets a note, a confidence estimate and a concrete way to check it: the imprint, the about page or the commercial register. Then a human signs it off.

The outcome: the list loses no row without a reason, and every interpreted hit carries the name of whoever confirmed it.

A name hit is a candidate

The weakest of the four keys is the company name. To make two spellings comparable the legal form is dropped, accents are flattened and spaces disappear. That is exactly what collapses unrelated firms onto each other: two offices that both carry their town plus their trade in the name look identical afterwards.

Our take: verify before merging, do not assert. A name hit opens the question, it does not answer it. Four things answer it: the same domain, the same commercial register number, the same address or the same responsible people, or a redirect from one web address to the other.

The effort is smaller than it sounds, because the name stage only applies once the three keys above it came back empty. On a maintained list that leaves a handful of rows, and those are worth two minutes each.

Flag, do not delete

A deleted row cannot be audited. The client can then neither check who was excluded nor object — the suppression has to be taken on trust. That gets uncomfortable at exactly the moment they miss a name they would have been glad to contact.

Our take: every suppression carries a reason and stays visible. The row gets a flag, the reason in plain language and a view of its own. Deleting for good is the client's decision.

For the rule to be more than a paragraph, the pipeline has to be able to stop here. The handover into the sending tool fails while a row is undecided, and only released rows are carried over. The rest is skipped visibly. Without that stop, the rule is a request to whoever uploads the list.

What Clay handles, and what stands beside it

"Doesn't the tool do that?" otherwise ends every conversation about list quality. The honest answer separates two kinds of work: the exact work at scale and the interpretive work on single cases. Rely on an exact check where the data is not exact, and you get a clean log of a dirty list.

Our take: Clay owns the exact work at scale — suppression against the CRM on domain, person email and exact company name, plus contact enrichment. Beside it stands the interpretive layer: consolidating several sources into one list, the cases a string comparison cannot see, and signing off whatever the tool itself reports as low confidence. That a company runs two domains is something a person sees in ten seconds and an exact rule never does.

The same division applies to the CRM. HubSpot is the source you suppress against, and the source of record IDs and domains. It is not the source for whether two spellings mean the same company.

Three questions that settle the state of your list

You do not need access to the pipeline to tell whether the match holds. Three questions are enough, and all three fit into one conversation. Anyone who answers all three concretely has built a reliable match. Anyone who turns vague on the first has not.

Ask these three before the next campaign, not after it. Once the send has gone out, all you can count is who replied — and the existing customer who raised an eyebrow usually does not. For how this fits the wider motion, see our page on pipeline generation.