Contact Selection: 3 People Per Account

The account list is clean, the enrichment tool has run, the sequence is built. And the campaign still reaches, in account after account, people who can neither trigger a purchase nor block one. Rewriting the copy at that point fixes the wrong layer.

Contact selection is not a filter you apply at the end of prospecting. It is a process of its own, and it decides before enrichment and before list hygiene. A perfectly enriched list of the wrong people is still the wrong list.

The symptom: clean, enriched, and missing the buying committee

There is a quick test for whether selection rather than copy is the problem. Count how many contacts per account sit in the running campaign, and how many of them hold a decision role. If the first number is in double digits and the second is zero or one, more copy work is wasted work.

The instinct runs the other way. When replies dry up, "more contacts per company" looks like the obvious correction, and the data source hands them over willingly. The cost lands on a different account: several messages into the same company on the same day is the pattern spam filters detect reliably, and domain reputation pays that bill for every campaign that follows.

An account is three searches, not one

Once the company list is fixed, it splits into three sourcing universes. Which one applies is decided by the available key, not by the company — and the order is a cost decision: exhaust free coverage first, pay for enrichment second.

Universe C is the part most lists quietly write off. The remainder after the first two passes is not an edge case, it is core scope: these are precisely the companies no competitor has emailed, because their tool never surfaced them. Researching the company website returns a name and a role there, and where it does not, it returns nothing at all. That is the correct outcome. An empty field beats a wrong contact.

Tiering is the only prioritisation

Before a single row is selected, the list needs a scheme a script can read. Job titles map onto tiers: decision-makers first, then project ownership, then the specialist role that formulates the requirement. One tier belongs in there deliberately even though it does not decide — the role that sits early in the process and is therefore close to the buying window.

Disqualifiers go into the same document: junior and assistant roles, plus sales, marketing, finance and HR unless one of them is the target role itself. They move to a backup list with a reason attached, never to the bin.

And the trap that catches every title-based rule is the false friend. "Owner" is not "project owner", and "Head of Sales" is a different target from "Head of Sales Support". Pairs like these belong in the tiering document by name, or the reply to your first email is where you find them.

Tune first, automate second, scale third

The selection itself is built on a ladder, and every rung has a purpose. An agent runs first, over a small set of accounts, and it runs until the edges are settled: the false friends, the dual roles, the titles written in a second language. That is thinking work, not throughput.

Once it is clear which titles actually carry, a deterministic script takes over. It costs nothing, it runs instantly, and above all it is auditable. Anyone asking why a person was selected reads a rule instead of interrogating a model.

Then comes the cross-check. Script and agent run over the same set and the mismatches get resolved one by one. That round is not ceremony: it finds the cases where the rule is too narrow, and it finds the ones where the agent guessed. Only then does the logic go to the full list.

That last point is where most builds fail. An agent that finds, classifies and writes to the table in a single pass has three chances to hallucinate and not one place where anyone could check which of them it took. One responsibility per step is not a matter of taste.

Two lists, nothing deleted

Selection ends with two lists, not one. The first carries a maximum of three contacts per account, each at the best available tier. The second is the backup pool: everything disqualified or de-prioritised, with the reason beside it. That second list is why a follow-up wave weeks later can start without any new research.

The cap of three is not a cost measure, it is a deliverability rule. And a second rule sits next to it: never send the same asset to several people at one company on the same day. The tiers stagger the waves — tier one first, the next tier follows with distance and with a different angle.

Employment verification is mandatory, not a nicety

Between research and send there is a step that adds nothing: checking that every person still works there. It gets skipped because it wins no rows, and it takes revenge twice. An email to a dead address is a hard bounce, and hard bounces are the currency inbox providers use to rate a sender. The second cost is reputation: a message to somebody who left a year ago tells the recipient exactly how carefully the list was built.

Invalid profiles get flagged in the same pass. And there is an honest limit worth telling a client rather than talking around: without a profile, some uncertainty remains until the first email goes out. It can be reduced, not removed.

LinkedIn activity works as a recency signal, but only an original post does. Shares carry no reliable timestamp and are worthless as a signal. Anyone who has not posted in recent weeks gets an email in the first wave rather than a connection request.

The suppression check is a cascade, not a domain match

Do-not-contact is usually built as a domain match, and that is exactly where it fails. People change companies, a subsidiary runs its own domain, a project partner shows up under a brand the suppression list never mentions. So the check needs five stages that fire in sequence.

Three inventories feed the suppression source: the client's own list, their project partners, and anything attributable to a competitor. Matched rows get flagged and carry a reason. Nothing is deleted — a deleted row walks straight back in at the next list build, a flagged one does not.

And the check runs as early as the list allows: before paid enrichment. Credits spent on a contact who is suppressed anyway are the most easily avoided line item in the whole process.

Where Clay belongs, and where Lemlist does

The tools sit at the end of this article on purpose, not at the start. The process decides which tool gets which job, not the other way round.

Clay is the coverage layer: contact search by company profile and domain, enrichment, employment verification and the activity lookup all run there, because they need many sources at once. SalesPlaybook is listed in the Clay Solutions Partner Directory as an "Artisan" partner of Clay, the entry level of four. The selection script sits above Clay, not inside it.

Lemlist is the sending layer, and it additionally dedupes against existing campaigns on upload. That is a useful last barrier and explicitly not the first one: whatever it catches should have been caught three steps earlier.

LinkedIn carries two roles here that should not be confused: the company URL is the most reliable sourcing key, and the person's profile is the identity evidence for employment verification and the suppression cascade.

That selection beats volume is evidenced in our own projects. node.energy generates 5x more demos in three months through targeted outbound with Clay integrated into HubSpot — the case study names the approach explicitly as signal-based outbound rather than mass outreach. At VARIO, six-figure monthly new-customer revenue sits alongside six target-account meetings booked in a single day.

How to tell that selection was skipped

Three symptoms give it away, and all three can be checked in half an hour. First, the number of contacts per account varies wildly, because it depends on whatever the data source happened to return. Second, there is no backup list, because disqualified rows were deleted. Third, nobody can say why a particular person was contacted — the criterion lives only in a prompt or in somebody's head.

The repair is not a rebuild. It starts by writing the tiering down and holding the existing list against it once. What falls out never belonged in the campaign, and what remains is a smaller list that actually lands.

This article sits ahead of three neighbouring steps we have described separately: list hygiene before the outbound send cleans what is already there, lead enrichment before outbound adds fields, and lead qualification orders what is already on the list. This step comes before all of them and asks who gets on it at all. How the whole thing fits into a system is on our pipeline generation page.