The Disqualification Layer: Why My Outbound System Deletes More Than It Finds

Most outbound content is about finding companies. Channels, scrapers, directories, intent platforms — the entire genre is a search problem.

After eighteen months of building a lead system for industrial exports out of Nanjing, I've concluded the search problem is the easy half. My sourcing channels can produce more companies than I can ever email. What determines whether the campaign works is the part that runs immediately afterward and throws most of them away.

On one recent batch, the screen took 36 sourced companies down to 11. That's a 69% kill rate before a single word of copy was written. The system I run is deliberately built so that the deletion logic is heavier, stricter and more documented than the acquisition logic.

And the most important rule inside that deletion logic is one I've never seen written down in English: your disqualification criteria are calibrated for developed markets, and if you apply them unmodified to emerging markets, you will delete your best buyers.

The shape of the system

Three stages, with a hard line about which parts a human owns.

Stage A — human-led. Deduplication gate, sourcing, screening, email collection, verification.
Stage B — machine-led. Deep research on survivors, then drafting.
Stage C — semi-automated. I send. The system tracks, schedules follow-ups, and files replies back into the dataset.

Four things the automation is never allowed to do: send email on my behalf, operate my Alibaba account, take over my WhatsApp or inbox, or commit to a price, lead time or term. Those aren't technical limitations. They're the boundary where an error stops being a bad email and starts being a business liability.

Everything interesting happens in Stage A.

Step 0: the deduplication gate

Before any sourcing run, candidates are checked against a running exclusion file of companies already contacted. Three outcomes:

- BLOCK — exact email match. Removed silently. No research, no email.
- WARN — domain match, or company-name fuzzy match above 85% similarity. Flagged for me to confirm by hand.
- PASS — clean. Proceeds to sourcing.

The fuzzy tier exists because company names are unstable across sources. The same firm appears as "Acme Electrical Ltd", "Acme Electric LLC" and "ACME ELECTRICALS" across a directory, LinkedIn and a customs record. Exact-match dedup catches none of it, and you end up emailing a company for the third time while believing it's a fresh lead. Normalizing away legal suffixes before comparison catches most of it.

This gate is boring and it is the highest-ROI component in the system. Nothing damages a reply rate like being visibly unable to remember who you already contacted.

Step 1: the four-step screen

Every surviving company runs a fixed sequence.

Website reality check. Does it load? Is the content real, or template placeholder text? Are there actual product pages, project pages, contact details? Does the domain's country match the country the company claims? A European TLD on a company presenting itself as African is a flag, not a disqualification.

Buyer profile match. I rank customer types explicitly rather than treating "electrical company" as a category:

Type Fit
Electrical distributor / wholesaler Best
EPC contractor Best - high project procurement
Systems integrator Strong - needs components
Small panel builder Moderate - may buy components
Mid-to-large manufacturer Weak - competitor, possible partner
Pure manufacturer Usually eliminate
Retail e-commerce / content blog Eliminate

Impostor detection. Four recurring patterns, each with its own signatures. I'll cover these below.

Decision. One flag marks the record. Two flags suggest elimination. Three or more eliminate automatically.

Step 2: the four impostor patterns

This is the part that has no equivalent in SaaS outbound, because in SaaS the companies on your list are real. In global industrial trade a meaningful fraction of what looks like a foreign buyer is not one.

Pattern A — trading company presenting as a local buyer. Signatures cluster: a foreign TLD, a registered address and phone code from a different country than the one claimed, tax identifiers in a format belonging to that other country, and a contact email whose domain doesn't match the website's. Individually each is weak. Together they're conclusive.

Pattern B — a domestic manufacturer presenting as an overseas company. Residual native-language artifacts in page source, a mail domain from the manufacturer's home country, two addresses coexisting on the contact page. I catch these constantly, and they matter more than you'd think: emailing a competitor a detailed capability pitch is worse than wasting a send.

Pattern C — marketplace listing pages masquerading as company sites. URL paths containing manufacturer/supplier segments, a single product page and nothing else, and — the fastest tell — images hotlinked from a B2B marketplace's CDN, or footer markup left over from a free site builder. Free-mail contact addresses on a supposed corporate site reinforce it.

Pattern D — content farms. Only "how to" and "X vs Y" articles. No product page, no project page, no team page. URL structures that betray a generic CMS blog template. No LinkedIn presence, or one with two employees. These rank well in search, which is exactly why they end up in scraped lists.

Every one of these patterns exists because the underlying source — a directory, a marketplace, a search scrape — has no incentive to distinguish a real importer from a page that ranks for importer keywords.

Step 3: the calibration rule that makes the whole thing work

Here's the part I actually want to argue for.

Run the four patterns above with Western defaults and you'll produce a list that is clean, defensible, and missing most of your real market.

Three concrete cases from my own screening:

Free email as corporate email. In Western Europe, Japan or the UAE, a distributor using a free mail account for business is a legitimate flag. In Bangladesh, Nigeria, Pakistan or Ethiopia it is ordinary practice at companies doing serious volume. Flag it there and you delete a large share of a real market.

Mobile-only, no landline. A red flag in a developed market. Normal in most of Africa and South Asia, where messaging apps are the primary business channel and a landline signals nothing except an older office.

Multiple unrelated business lines. In a Western context, an electrical distributor also selling generators, doing construction and importing tiles reads as unfocused or fake. In MENA and South Asian family businesses it's the standard structure, and often indicates exactly the capital base and import experience you want in a partner.

So the calibration runs before flags are counted, not after. The screen asks first: what's normal for a company of this size, in this country, in this decade? Then it evaluates. A rule that produces the right answer in Munich and the wrong answer in Dhaka isn't a quality standard. It's a geographic filter wearing one.

I think this is the single most transferable idea in my system, and it generalizes past my industry: every list-hygiene heuristic encodes assumptions about the market it was written in. If your ICP is somewhere other than where the playbook was written, the heuristics need re-deriving, not importing.

Step 4: contact discovery, with a prohibition

Once a company survives, the system looks for a named decision-maker across LinkedIn, the company's own team and about pages, social profiles, and national business registries. Then one hard rule:

Guessing email format is forbidden.

Not discouraged — forbidden. The format must be confirmed against an aggregator or a documented public instance before an address is used. If it can't be confirmed, the record says "not found — needs manual search" and goes no further.

The reason is arithmetic. Pattern-guessed addresses bounce, bounces damage domain reputation, and a damaged domain silently degrades every campaign that follows for weeks. A guessed address that happens to be right saves ten minutes. A guessed address that's wrong costs a month.

Everything that survives goes through bulk verification, and only results returning a clean status are kept. In one recent run, 62% of collected addresses passed — the full survival numbers and what the pipeline costs are here [/blog/ai-outbound-pipeline-yield]. Each company keeps two to three addresses: the named decision-maker, a role address, and a fallback — plus a non-email channel where one exists.

One thing that surprised me: the same company frequently holds multiple live domains, including legacy ones from before a rebrand or an acquisition. Reverse cross-referencing verified addresses back against known company domains catches these merges. It also catches something more important — companies that have been acquired by a major brand, which changes their signal profile entirely.

The anti-hallucination rules

Because most of the research is machine-executed, the system carries six standing rules that outrank every other instruction:

1. Every factual claim — name, title, email, project, figure — must carry a traceable source URL.
2. Anything not found is written as "not found." Inference to fill gaps is prohibited.
3. A list I supply myself is not an authoritative source. Every name is independently verified.
4. Product certification claims are checked line by line against what we actually hold. Claiming a certification we don't have, because it sounds credible, is an unrecoverable error.
5. Every outbound email ships with a sentence-by-sentence translation and per-sentence source, so I can verify it before sending.
6. Decision-maker details are never fabricated. Not found means not found.

Rule 4 deserves emphasis for anyone selling regulated hardware. Certification language is a legal exposure, not a selling point, and a language model with no grounding will absolutely write a certification into your email because it makes the sentence stronger. I wrote about this constraint and the rest of the compliance layer in my first post on cold emailing without a trigger event [/blog/cold-email-no-trigger-event].

Where my own system and my own results disagree

Now the uncomfortable part.

The signal engine scores companies against sixteen signal categories — customs import surges, tender awards, contract wins, expansion announcements, leadership changes, hiring spikes, exhibition attendance and so on — with combination bonuses when several fire together, because multiple simultaneous signals indicate genuine buying intent rather than noise.

And it carries an iron rule:

Weak signals — static facts like founding year, headcount, or holding a brand distributorship — do not justify an email. Strong signals — a dynamic event — trigger drafting immediately. No signal means the account is parked and waits.

That rule says, unambiguously, that the campaign I published my first post about should not have been sent. In that batch, 111 of 128 accounts had no dynamic signal at all. I emailed them anyway, using exactly the kind of static brand-relationship fact my own system classifies as insufficient. It produced three positive replies — below the average benchmark for overall reply rate, above it for positive replies.

I'm not going to resolve this cleanly, because I haven't earned a resolution. Three honest readings:

1. The iron rule is right and I got lucky. Three replies is not a sample. A signal-gated campaign might have produced the same replies from a tenth of the sends.
2. The iron rule is right about priority, wrong about permission. Signals should determine order and effort, not whether an account is contactable at all. Parking 87% of a market indefinitely is not a strategy when signals in that market are structurally scarce.
3. The iron rule was written for a market that generates signals. Customs surges, tender awards and hiring spikes are all detectable in some countries and effectively invisible in others. A rule that gates outreach on detectable events quietly gates it on data availability.

I lean toward the second and third. But I built the first rule myself, deliberately, and I'm not going to pretend I've disproven it with three replies.

The reason I can't settle this yet is a measurement failure I've already admitted: I didn't tag replies by signal tier. So I cannot tell you whether those three came from the seven signal-bearing accounts or the 111 without. That tagging is now mandatory on every send, and when there's enough data I'll publish the split whichever way it falls — including if it says my own system was right and I was wrong to override it.

What I'd tell someone building this

Write the disqualification rules before the sourcing rules. Sourcing capacity is not your constraint. Judgment is.

Make "not found" a legal output. Any research system that can't return nothing will return fiction instead.

Audit your heuristics for where they were written. This is the one that cost me the most to learn. Most outbound advice, including most of the good advice, was written by people selling software to companies in North America and Western Europe. The tactics port. The disqualification criteria do not, and they're the part that silently deletes your market.

Separate what a machine decides from what it executes. Research, scoring and drafting are fine to automate. Sending, pricing and committing are not — not because the machine is bad at them, but because the failure mode is unbounded.

--------------------------------------------------------------------

Second of three posts on running outbound from Nanjing into emerging markets. The first covers what I do when a prospect generates no signals at all [/blog/cold-email-no-trigger-event] — including the campaign this post argues my own system should have blocked.