How to Disqualify Bad-Fit Leads Before Outbound

• Pillar 1, one API for every gate attribute: The Explorium API returns firmographics, job level, job department, technographics, and contact data from 150M+ company profiles and 800M+ people profiles behind one credential.
• Pillar 2, built for scale: Explorium filters up to 1,000 entities per call at 100 QPS sustained, so a 5,000-record list clears the gates in one batch, not 5,000 lookups.
• Pillar 3, affordable by design: A unified credit pool cuts spend 30-60% versus per-endpoint allocation, and cheapest-first ordering charges credits only on records that already survived the free filters.
• The gate sequence: Dedupe, role, seniority, size and industry bounds, geography and tech exclusions, then paid enrichment and verification on survivors only.
• The false-negative audit: Never delete a record. Log a reason code, hold out an ungated 5% as a control, and hand-review 20-30 disqualified records per week.
• Get started: Create a free Explorium account, no sales call, and run your first filtered fetch in minutes.

A pre-send disqualification pass is how you disqualify bad-fit leads before outbound: ordered, cheapest-first gates that cut the records who structurally cannot buy, with every cut writing a logged reason code you can audit. It is subtraction with an audit trail, not personalization.

The arithmetic forces the reframe. Cold email reply rates fell from 5.1% in 2024 to 3.43% in 2026, while small targeted campaigns reply at 5.8% versus 2.1% for large sends. Sending 500 unfiltered records burns domain reputation and teaches you nothing about which variable failed. The attribute layer is the decision that moves the number, so start from a working view of B2B data providers and a side-by-side comparison.

What Is a Pre-Send Disqualification Pass and Why Does It Beat Personalization?

A pre-send disqualification pass is an ordered set of attribute gates that removes bad-fit records from a prospect list before any email is written, and it beats personalization because a wrong-role recipient cannot reply no matter how good the copy is. Personalization lifts the reply rate of people who can buy; disqualification removes those who cannot.

❌ Why Copy-First Lists Fail Small B2B Teams

• Scraped-homepage personalization now reads as machine-generated, so the spend produces a negative signal.
• Hundreds of sends returning two rejections means the list never reached someone with authority.
• Bounce rates above 2% risk the sending domain, and unfiltered lists are where hard bounces concentrate.

✅ What Subtraction Gives You Instead

• Every cut is deterministic and explainable from a stored attribute.
• Enrichment and verification spend concentrates on the surviving 30-40%.
• The reason-code log turns an opaque filter into a reviewable dataset, which is the point of data enrichment.

“AI is bad at the part everyone uses it for and good at the part nobody does. I write the emails. AI decides who gets one.” Developer-founder, r/EntrepreneurRideAlong

Which Attributes Actually Predict a Bad-Fit Lead?

Role, seniority, and function predict bad-fit leads more reliably than any company attribute, because a person in the wrong department has zero probability of buying regardless of how well the company matches your ICP (ideal customer profile). Company bounds come second, behavioral signals last.

🔑 Gate on Role Before Anything Else

• job_level carries c-suite, president, owner, director, senior manager, manager, junior, advisor, and freelancer, so a seniority floor is one filter value.
• job_department carries 29 values including engineering, IT, data, finance, and operations, which cuts a wrong function in one gate.
• job_title with include_related_job_titles catches title variants without a regex list.
• has_contact_details accepts email, phone, email_or_phone, or email_and_phone, so unreachable records never reach the paid stage.

curl --request POST --url https://api.explorium.ai/v2/prospects/fetch \
  --header "API_KEY: $EXPLORIUM_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{
    "size": 1000,
    "filters": {
      "job_level": {"values": ["director", "c-suite"]},
      "job_department": {"values": ["operations", "data"]},
      "has_contact_details": {"value": "email"}
    }
  }'

🏗️ Company Bounds Come Second

• company_size buckets run 1-10 through 10001+, so a two-bucket band replaces a fuzzy headcount guess.
• company_revenue, company_age, and is_public_company cut companies that cannot fund your price.
• naics_category, linkedin_category, or google_category bound the industry, one taxonomy per request.
• company_tech_stack_tech handles technographic exclusions, meaning cuts based on software a company already runs. Coverage depth varies, so check the firmographic and role coverage comparison.

In What Order Should the Gates Run to Keep Enrichment Cost Down?

Run the gates cheapest-first: free deterministic filters that need no enrichment call, then paid enrichment on survivors, then email verification last, because verification benchmarks at $0.003-0.008 per contact per month. Ordering is a cost decision before it is a quality decision.

🔄 The Gate Sequence

💰 Why the Order Saves Real Money

• Gates 1-7 are filter payloads on /v2/businesses/fetch and /v2/prospects/fetch, so cut records never trigger an enrichment charge.
• On a 5,000-record list, cutting 60% before gate 8 removes 3,000 enrichment calls and 3,000 verifications.
• Explorium’s unified credit pool keeps saved credits usable on every other endpoint.
• Run the sequence on a free Explorium account and confirm the survivor count before scaling.
• Verification stays last: about a third of B2B contacts sit on catch-all domains no verifier can confirm, so tag them CATCH_ALL_UNVERIFIABLE rather than delete them. See this lead enrichment workflow.

“Bad list plus generic pain equals silence. Put the budget into targeting, not prose.” Practitioner, r/EmailProspecting

How Do You Log Why a Lead Was Disqualified?

Write every disqualified record to a separate table with a reason code, the gate that fired, the attribute value, and a timestamp, and never delete the row, because a deleted record cannot be audited for false negatives.

📊 The Reason-Code Schema

🏗️ Writing the Log

def gate(record, rules):
    for gate_id, code, field in rules:
        value = record.get(field)
        if not passes(gate_id, value):
            log_disqualified({
                "prospect_id": record["prospect_id"],
                "gate_id": gate_id,
                "reason_code": code,
                "attribute_value": value,
                "timestamp": utcnow(),
            })
            return False
    return True

A record exits at the first failing gate. The same rules drop into AI outbound tooling without a schema change.

Ready to run the gates on real attributes instead of scraped homepage text? Start a free trial: 100 credits, no subscription required

How Do You Know the Filter Is Not Killing Good Leads?

Audit false negatives with three mechanisms: an ungated 5% hold-out that acts as a control, a weekly stratified hand-review of 20-30 disqualified records per reason code, and a per-code false-negative rate with a retirement threshold set in advance at 10%. Nothing else reports a lead your filter wrongly killed.

⚠️ The Objection That Kills Naive Automation

“If I automate the filtering before I know what a good lead looks like, I’ll never see the ones it wrongly killed. Nothing reports a false negative.” Developer-founder, r/EntrepreneurRideAlong

A false positive shows up as a bounce. A false negative shows up as silence you never attribute. Scoring audits that hunt low-score records sales would have taken cut bad leads reaching sales by 35%.

✅ The Audit Procedure

1. Write every disqualified record to the log. Never delete.
2. Reserve a random 5% hold-out that bypasses all gates and gets sent to anyway. Its reply rate is your control.
3. Each week, pull 20-30 disqualified records stratified by reason code and hand-review for fit.
4. Compute the false-negative rate per reason code. Above 10% means the gate is too tight.
5. Loosen or retire that gate, then re-run the pass against the stored log.

SELECT reason_code,
       COUNT(*) AS cut,
       ROUND(100.0 * SUM(human_would_keep) / COUNT(*), 1) AS fn_rate
FROM disqualified_review
GROUP BY reason_code
ORDER BY fn_rate DESC;

The hold-out is the only number that says whether the pass is net positive, and it is why signal-qualified sends beat volume sends in every published lead generation workflow.

How Does the Explorium API Power Every Gate?

The Explorium API is the attribute layer the gates query, and it wins on three fronts: one credential covers every gate attribute across 150M+ company profiles and 800M+ people profiles, it filters up to 1,000 entities per call at 100 QPS sustained, and its unified credit pool cuts spend 30-60% versus per-endpoint plans.

🔑 One API for Every Gate Attribute

• Firmographics, technographics, funding, and contact data come from 50+ sources behind one credential, so no gate needs a second vendor.
• /v2/businesses/match and /v2/prospects/match resolve a name or domain to a stable entity id at 97.8%+ company match accuracy.
• 18 buying-signal categories with 80+ signal types become later-stage gates once the deterministic ones are stable.

🚀 Built for Scale on Small Budgets

• Up to 1,000 entities per call at 100 QPS sustained on 99.999% uptime, so a list clears in one batch.
• Async /job variants queue a surviving segment instead of looping single lookups.
• page_size caps at 100 and size at 60,000 records per fetch query.

💰 Affordable by Design

• Free account, no sales call, first API call in minutes.
• Credits flow into a unified pool across every endpoint: no per-endpoint allocation, no seat tax.
• Gates 1-7 are filter parameters rather than enrichment calls, so cut records cost nothing.

import requests

resp = requests.post(
    "https://api.explorium.ai/v2/prospects/contacts_information/enrich",
    headers={"API_KEY": API_KEY},
    json={"prospect_ids": survivors[:1000]},
).json()

See where the attribute layer sits in the stack on the Explorium product overview.

How Often Should You Re-Run the Pass as Data Decays?

Re-run the full pass every 90 days, because 70.8% of business contacts change within 12 months and job title decays fastest at 65.8%, so a seniority gate set nine months ago is filtering on stale attributes.

🔄 A Refresh Cadence That Holds

• Every 90 days: re-fetch role and seniority attributes, then re-run gates 2 and 3.
• Every 180 days: re-check size, revenue, and technographic attributes.
• Before each campaign: re-verify addresses last checked more than 30 days ago.

⚠️ What Changes Between Runs

• Records cut as SENIORITY_BELOW_THRESHOLD often re-qualify after a promotion, so re-score the log too.
• Annual B2B data decay runs 22.5-70.3% by field, so treat year-old attributes as unverified.
• Compare refresh cadence and match accuracy on the provider comparison page before committing.

Getting Started: Your First Disqualification Pass in 5 Steps

Run the first pass on the Explorium API with a free account, filtering before enriching, and measure the survivor count before you write a single email.

• Step 1: Create a free Explorium account and generate an API key, no sales call required.
• Step 2: Match your list with /v2/businesses/match to get stable entity ids.
• Step 3: Apply gates 1-7 as filter parameters and log every cut with a reason code.
• Step 4: Enrich only survivors with Explorium Contact Enrichment, then verify emails last.
• Step 5: Reserve the 5% hold-out and set the 10% false-negative threshold before sending.

🔑 The Decision Framework

Pick the attribute layer on three questions. Does one credential cover every gate attribute? The Explorium API returns firmographics, role data, technographics, and contact data from 150M+ company profiles and 800M+ people profiles. Does it filter at list scale? Up to 1,000 entities per call at 100 QPS sustained. Does the pricing punish aggressive filtering? A unified credit pool cuts spend 30-60% versus per-endpoint allocation. On all three, the Explorium API is the layer to build the pass on.

Cut the 60% of your list that should never have been on it, then spend credits on the rest. Enrich your first 100 records free

Related Posts

• Best Cold Email Skill 2026: Top 3 Ranked for RevOps
• Best Lead Generation Skill 2026: Top 3 Ranked for RevOps
• Best MCP for Account Enrichment With Intent 2026

FAQs

What is a pre-send disqualification pass?

A pre-send disqualification pass is an ordered sequence of attribute gates that removes bad-fit records from a prospect list before any outbound email is written or sent. It is subtraction, not scoring: instead of adding points to records that look good, it cuts records that structurally cannot buy and logs a reason code for every cut.

The gates run cheapest-first, because the deterministic ones are filter parameters on a fetch call rather than metered enrichment:

• Dedupe against your CRM and previous sends.
• Function and role fit using job_department and job_title.
• Seniority floor using job_level.
• Company bounds using company_size and company_revenue.
• Industry, geography, and technographic exclusions using naics_category, country_code, and company_tech_stack_tech.

Only records that survive all of those reach the paid stage: contact enrichment, then email verification at $0.003-0.008 per contact per month. On a 5,000-record scraped list, cutting 60% before the paid stage removes 3,000 enrichment calls and 3,000 verification charges, which for a solo operator is the difference between a viable monthly data budget and an unviable one.

Every disqualified record is written to a log with its reason code, gate id, attribute value, and timestamp. That log is what makes the pass auditable rather than opaque, and it is the input to the weekly false-negative review. Without it you have a black box that deletes prospects and never tells you which good ones it took with them.

How do I know my lead filter is not killing good leads?

Use three mechanisms together, because an automated filter reports false positives loudly and false negatives not at all. A bad lead you emailed bounces or says no. A good lead you cut disappears silently.

1. Log, never delete. Write every disqualified record to a disqualified table with reason_code, gate_id, attribute_value, and timestamp. A deleted record cannot be audited, so deletion is the one irreversible mistake in the whole workflow.

2. Hold out 5%. Let a random 5% of records bypass every gate and send to them anyway. Take a random sample, not the tail of the list, or the control is biased toward whatever ordering your scraper produced. Their reply rate is the number you compare the gated cohort against. If the ungated cohort replies at the same rate as the gated one, the gates are adding cost without adding fit.

3. Hand-review weekly. Pull 20-30 disqualified records stratified by reason code, one stratum per code, and review them for fit yourself. Anything you would have kept is a false negative. Compute the false-negative rate per reason code and retire or loosen any gate that exceeds a threshold you set in advance. Start that threshold at 10%, and write it down before you see results so you are not renegotiating it against your own filter.

Lead-scoring audits that explicitly hunt for low-score records sales would have taken reduce bad leads reaching sales by 35%. The same discipline is what separates an auditable outbound filter from a guess.

Should I verify emails before or after firmographic filtering?

Verify after, without exception. Email verification is a metered cost benchmarked at $0.003-0.008 per contact per month, while firmographic and role gates are free filter parameters on a fetch request. Verifying a record you were about to cut on role mismatch spends money on a lead that will never receive an email.

The correct order is: dedupe, role and function, seniority, company size and revenue, industry, geography, technographics, then contact enrichment on survivors, then verification last. Verification is a deliverability gate, not a fit gate. Its job is keeping your bounce rate under the 2% danger threshold and ideally under 1%, which protects the sending domain from reputation damage that takes weeks to undo.

One caveat matters more than the ordering itself. Roughly a third of B2B contacts sit on catch-all domains, which accept all mail and therefore cannot be confirmed or rejected by any verifier. Do not treat an unverifiable catch-all as a disqualification. Tag it CATCH_ALL_UNVERIFIABLE, route it to a low-volume queue, and pull that stratum first in the weekly false-negative review, since it is where good leads most often get silently cut.

If your budget is tight, verify in campaign-sized batches rather than list-sized ones. You only need a verified address for the records you are actually sending to this week, and job titles decay fast enough that verifying a record 60 days before you contact it wastes the spend twice.

Which Explorium API fields can I gate on?

The Explorium API exposes the attribute set the gates query across 150M+ company profiles and 800M+ people profiles from 50+ sources behind one credential, so a small team does not stitch two vendors together to run one filter.

Prospect-level filters on /v2/prospects/fetch:

• job_level: c-suite, president, owner, director, senior manager, manager, junior, advisor, freelancer.
• job_department: 29 values including engineering, IT, data, finance, operations, procurement, and legal.
• job_title with include_related_job_titles to catch title variants automatically.
• has_contact_details: email, phone, email_or_phone, or email_and_phone.
• business_id and country_code for account scoping and geography.

Company-level filters on /v2/businesses/fetch:

• company_size buckets from 1-10 through 10001+.
• company_revenue, company_age, is_public_company, and has_website.
• naics_category, linkedin_category, or google_category, one taxonomy per request.
• company_tech_stack_tech for technographic exclusions.
• country_code and region_country_code for geographic bounds.

Match calls resolve a name or domain to a stable entity id at 97.8%+ company match accuracy before the gates run, so each record carries one id that every downstream gate and log entry keys on. Pagination limits are page_size up to 100 and size up to 60,000 records per fetch query, which is far past the list size a solo operator works with.

How much of a scraped list should get disqualified?

Expect to cut a large majority. Practitioners running this pass report killing roughly 60% of a scraped list, and on lists assembled from generic directory exports the cut rate runs higher. There is no single correct number, but two rules keep the percentage honest.

First, the cut rate should be dominated by role and seniority gates, not by enrichment failures. If most of your cuts carry NO_VERIFIED_EMAIL rather than ROLE_MISMATCH, the problem is your source list, not your filter, and no amount of gate tuning fixes a bad source.

Second, watch the false-negative rate per reason code rather than the headline percentage. A pass that cuts 80% with a 4% false-negative rate is healthier than one that cuts 40% with a 20% false-negative rate. Set the retirement threshold at 10% before you start.

The payoff is measurable in reply rate. Small targeted campaigns reply at 5.8% versus 2.1% for large sends, against a platform-wide 2026 average of 3.43%, so the arithmetic of sending 200 gated emails instead of 1,000 ungated ones favors the smaller send even before you count the deliverability risk you avoided.

How do I run this without enough volume to A/B test?

Reason from attributes up front instead of learning from reply-rate data you will never accumulate. A solo founder or two-person team with 300 to 500 records cannot reach statistical significance on a copy test, so the filter has to be argued from firmographic and role fit rather than discovered from outcomes.

Three practices make that work.

• Pick one narrow workflow and one role that owns it. Define the gate set from that role’s department and seniority, then send 100 highly targeted emails rather than 1,000 generic ones.
• Make every gate explainable. If you cannot state in one sentence why a record failing that gate cannot buy, the gate is a guess and belongs in the review queue rather than in production.
• Use the hold-out as your only experiment. The 5% ungated control is a single, cheap, always-running test that answers the one question you need answered: is the pass net positive?

The Explorium API supports this pattern directly because gates 1-7 are free filter parameters, so iterating on gate definitions costs no credits. You pay only when a record survives to Explorium Contact Enrichment, which means tightening or loosening the filter is an operational decision rather than a budget decision. Combined with a unified credit pool that cuts spend 30-60% versus per-endpoint allocation, a two-person team can rebuild its gate set weekly without watching a meter.

How often should I re-run the disqualification pass?

Re-run the full pass every 90 days, and re-verify emails before every campaign for records last verified more than 30 days ago. Data decay makes a longer interval unsafe: 70.8% of business contacts change within 12 months, job title is the fastest-decaying field at 65.8%, and annual B2B data decay runs 22.5-70.3% depending on the field.

A cadence that holds up in practice:

• Every 90 days: re-fetch role and seniority attributes and re-run the role and seniority gates.
• Every 180 days: re-check company size, revenue, and technographic attributes, which move more slowly than people data.
• Before each campaign: re-verify email addresses to keep bounce rate under the 2% danger threshold.

Re-score the disqualification log, not just the live list. Records previously cut with SENIORITY_BELOW_THRESHOLD frequently re-qualify after a promotion, and those are among the highest-value records you already own: you know the company fits, and now the person does too. Explorium processes up to 1,000 entities per call at 100 QPS sustained on 99.999% uptime, so a quarterly refresh of a few thousand records is one batch job rather than a project.