Warm Leads: What a CRM Export Can't Prove

Most teams answer it with a CRM export, because an export looks like evidence. It is not. An export tells you what your database contains. Whether a relationship exists is a second question, and five things routinely make the answer wrong. The expensive failure is not the customer you missed. It is the Lead you addressed as a customer.

Warm is a claim that needs a reason

A company is warm when you can name the specific thing you share, such as a past project, a referral, or a conversation someone remembers. Anything weaker is cold with extra steps. Thin presence in a database is not a relationship, and treating it as one produces a first line that sounds informed and lands as presumptuous.

The business cost is asymmetric, which is why the decision deserves its own step. Missing a prospect costs one opportunity. Sending a new-business sequence to an account that has been paying for two years costs credibility with the exact person who defended the engagement internally. Worse still is the account sitting in your Pipeline as an open Deal while a cold sequence reaches the same building.

Our position: we build the cold-warm split as a research step with a readable result, never as a formula in a spreadsheet column. A formula always returns an answer, including when the underlying data supports none.

A file name is not a data source

An export called all-customers is not a list of customers. It is the output of a filter somebody set once, carrying a name nobody revisited. Read the name as a statement and you inherit a decision whose reasoning is gone.

Here is how that shows up. A file of roughly eight hundred rows has the word customers in its title. Read the stage column and several dozen rows say something else, spread across Leads, qualified contacts, and open Deals. Treat the file as customers wholesale and one of those Leads ends up described as an existing customer in an email to the client.

The fix is unglamorous. Resolve the stage per row from the column built for it, which in HubSpot is the Lifecycle Stage. Then map stage to tier once, document it, and apply it to every row identically. Never infer relationship status from a file name, a tab name, or an export's mere contents.

The result is a status you can audit. When an assignment looks wrong later, you can show where it came from.

A slice cannot establish absence

Matching against a slice can only surface what the slice holds. That is fine while you are looking for hits. It stops being fine the moment a missing hit becomes permission to send, which is precisely what happens when a customer export is used as the suppression list.

The gap is an order of magnitude, not a rounding error. A customer export is a subset. The full company export is frequently many times larger and contains every company ever created, each with its stage. Match only against the subset and accounts look cold despite a documented history.

Our position: suppression needs the full population, prioritisation does not. So the status question always runs against the complete company export, even when it is twenty times the size and the check takes longer. The subset answers a narrower question than it appears to answer.

One company, two answers

Systems that grew through mergers hold the same company more than once, with records that disagree. This is not junk data. It is the ordinary consequence of consolidations, renamings, and two teams creating the same account independently. A group with four subsidiaries shows up four times, in four spellings, across three stages.

The error happens on read, not on write. Most matching logic keeps the first record per company and discards the rest, which hands the decision to the sort order of a file. The contradiction then disappears before anyone sees it.

Do the opposite. Keep every hit, take the most conservative stage, and surface the disagreement as its own flag. The row then carries a stage and the fact that a second one exists. Resolving it belongs to the client, who knows their own corporate structure, and not to a sort order.

A shared domain invents relationships

A contact carrying a company's email domain is not evidence of a relationship with that company. It is evidence that an address was recorded. Promote that address to a matching key and you manufacture relationships that never existed, in a form that looks verified.

The mechanism is simple, which is why it is common. When an external consultant's address is written onto every company they advise, nine companies end up sharing one domain. A domain-level match then reports a known contact for all nine. None of those contacts is theirs.

Count before you key. Before a domain is used for matching, count how many distinct companies carry it in the master list. More than one and it is disqualified as a key, flagged for correction, and any relationship claim resting on it is downgraded with the reason stated. A shared domain is not weak evidence. It is none.

Why your CRM cannot tier the list

Who decides inside a target account is the one thing your own system almost never holds reliably. Role fields are filled on a fraction of records, and what is there dates from whenever the contact was created. Prioritising on that basis sorts by data-entry discipline rather than by relevance.

That implies a division of labour. A CRM answers two questions well, namely who must not be contacted and who owns the account internally. Which person at the target company is the right one is answered better by public sources, so LinkedIn, commercial registers, and the company website. How many and which people per account is covered in our piece on contact selection, three people per account.

Our position: the CRM is a suppression and routing source, not a tiering source. That is not an apology for thin data. It is a methodology decision, and it is worth stating to a client in exactly those terms.

Deep Dive Guide · 15 pages · free

Which lead first

The ranking rule that belongs before the campaign, not after it. A matrix with two axes instead of one number and one action per cell.

Explore guide →

Flag, never delete, and hold what is unresolved

Taking a row out of the send is not the same as taking it out of the list. Delete it and the reason goes with it, so the next run starts the same investigation from scratch. A deleted row is indistinguishable from a row that never existed.

Every exclusion therefore carries a flag and a reason, filterable, in its own tab. Final deletion is the client's call, because only they know their relationships. The detail of that approach is in our piece on list hygiene before an outbound send.

The same logic covers incompleteness. If a surname or a salutation is still missing after the confident pass, the row goes to a hold pile instead of the send. Without a clean surname there is no correct opening line, and a broken salutation costs more than a contact reached a week later. Which fields the first email actually needs is covered in our piece on lead enrichment before outbound.

Deterministic first, semantic second

Logic that decides where it can only guess removes too much. A loose name match once took an entire trade out of a send because it matched on a generic leftover word. Nobody catches it at the time. It surfaces when the final count looks low, and by then no one knows which rule shrank it.

Sequence solves this. Auto-suppress only on an unambiguous hit, meaning root domain, person by domain, or an exactly identical normalised company name. Everything interpretive stays a proposal:

• Contracted domains and initialisms, where no string comparison will ever find the link
• Name variants of one company after a rebrand
• The same person behind two domains that look unrelated
• Company names that differ by a single word once the legal form is stripped

Each of these gets a flag, a confidence read, and a concrete validation to run, such as an imprint or a register entry. A human signs off. The exact matching at volume runs in Clay, where we are listed at the Artisan tier in the Clay Solutions Partner Directory; the interpretive layer and the sign-off deliberately stay outside the tool. Only then does the cleared list enter the sending tool, which for us is Lemlist.

Our position: a machine produces candidates and a person decides. It costs half an hour per run and prevents the error you cannot find afterwards. DeepOpinion describes the same effect for their own setup, that structure takes the guessing out: “align business needs into scalable Business setup and reduce guess work”.