Evidence-Based B2B Lead Qualification & Outreach

Turn a company list into evidence-backed ICP scores, buying-signal explanations, and ready-to-review LinkedIn and email outreach.

This Actor is designed around the result: prioritize the accounts worth a conversation and show why. You provide the offer, ICP, observable qualification criteria, hard disqualifiers, and target roles. The Actor researches each company, assesses only those criteria, validates citations, and calculates the final scores in code.

Best for

• agencies and consultants qualifying prospect lists;
• SDR and RevOps teams preparing CRM-ready research;
• founders testing an ICP before manual outreach;
• automation teams prioritizing accounts for human review.

It does not find personal emails, scrape LinkedIn, send messages, or replace a salesperson’s judgment.

What each result contains

• company description, industry, country, products, customers, and operating context;
• evidence-linked pain points and automation opportunities;
• one assessment for every configured qualification criterion;
• supported disqualifier matches;
• four deterministic scores;
• a concise LinkedIn DM and optional email;
• sources, evidence chunk IDs, warnings, and verification metadata.

Score meanings

Score	Meaning
icp_fit_score	Percentage of configured criteria assessed as match (1 point) or partial (0.5 point)
evidence_confidence_score	Confidence derived from evidence levels and valid citations
contact_relevance_score	Role similarity between the lead and configured target roles
outreach_readiness_score	55% ICP fit + 25% evidence + 20% contact relevance

A supported disqualifier caps ICP fit at 25 and outreach readiness at 30. The LLM never controls the final numeric scores.

Input example

{
  "leads": [
    {
      "fullName": "Mario Rossi",
      "jobTitle": "COO",
      "companyName": "Example Manufacturing",
      "companyUrl": "https://example.com",
      "notes": "Met at an industry event; evaluating process automation this quarter."
    }
  ],
  "offerDescription": "We automate document-heavy B2B operations by connecting ERP, CRM, email, and approval workflows with human-reviewed AI.",
  "idealCustomerProfile": "Italian mid-market manufacturers with multi-person operations teams, repetitive document workflows, and an active process-improvement initiative.",
  "qualificationCriteria": [
    "Operates document-heavy workflows",
    "Uses an ERP or CRM",
    "Has a multi-person operations team"
  ],
  "disqualifiers": ["Only serves consumers", "Has no operational team"],
  "targetRoles": ["COO", "Head of Operations", "Operations Director"],
  "targetIndustries": ["Manufacturing"],
  "targetCountries": ["Italy"],
  "outreachGoal": "Start a 15-minute discovery conversation about one operational workflow.",
  "aiProvider": "openrouter",
  "model": "openrouter/free",
  "researchProvider": "website-only",
  "researchDepth": "standard",
  "verificationMode": "deep",
  "language": "it",
  "messageStyle": "soft-consultative",
  "maxMessageChars": 300,
  "includeEmail": true,
  "maxConcurrency": 4
}

Use factual notes only. Writing “this company has the pain point I want” biases any qualification system.

Research and verification modes

Research depth

Value	Website behavior
homepage	Fetch the homepage
standard	Fetch the homepage and up to 3 useful internal pages
deep	Fetch the homepage and up to 5 useful internal pages

Website-only mode uses lightweight HTTP extraction. It does not render JavaScript or bypass anti-bot systems. Tavily mode adds public web search and extraction using the user’s Tavily key.

Verification mode

Value	Behavior	Store PPE event
standard	One analysis call plus deterministic guardrails and citation validation	apify-default-dataset-item
deep	Adds a second independent LLM evidence-checking pass	apify-default-dataset-item

The published Store pricing displays this event as lead and charges $20 per 1,000 results for both verification modes. Its technical event name is apify-default-dataset-item. AI and Tavily usage are BYO-key costs paid directly by the user.

Output example

{
  "status": "succeeded",
  "lead": {
    "full_name": "Mario Rossi",
    "job_title": "COO",
    "company_name": "Example Manufacturing",
    "company_url": "https://example.com",
    "linkedin_url": null
  },
  "qualification": {
    "icp_fit_score": 83,
    "evidence_confidence_score": 82,
    "contact_relevance_score": 100,
    "outreach_readiness_score": 86,
    "priority": "high",
    "criteria_assessment": [
      {
        "criterion": "Uses an ERP or CRM",
        "status": "match",
        "evidence_level": "direct",
        "evidence_urls": ["https://example.com/solutions"],
        "evidence_chunk_ids": ["example.com-solutions#1"],
        "rationale": "The solutions page explicitly mentions ERP integration."
      }
    ],
    "matched_criteria": ["Uses an ERP or CRM"],
    "partial_criteria": [],
    "missing_criteria": [],
    "disqualifier_matches": [],
    "reasons": ["The published workflow is aligned with the offer."],
    "red_flags": [],
    "score_breakdown": {
      "icp_fit_weight": 0.55,
      "evidence_confidence_weight": 0.25,
      "contact_relevance_weight": 0.2
    }
  },
  "outreach": {
    "why_now": "The company publishes an ERP integration workflow.",
    "icebreaker": "I noticed your ERP integration focus.",
    "linkedin_dm": "Ciao Mario, ho notato il focus sulle integrazioni ERP. Lavoriamo su workflow documentali e approvativi collegati ai sistemi esistenti. Ha senso confrontarci per 15 minuti su un processo concreto?",
    "email_subject": "Un workflow operativo da semplificare",
    "email_body": "...",
    "cta": "Confronto di 15 minuti?"
  },
  "sources": ["https://example.com/solutions"],
  "warnings": [],
  "evidence_checker": {
    "enabled": true,
    "evidence_chunks_checked": 8,
    "model_based_verification": true
  },
  "metadata": {
    "research_depth": "standard",
    "verification_mode": "deep",
    "byo_api_keys": true,
    "linkedin_scraped": false
  }
}

The example values are illustrative; real output depends on the supplied evidence.

Configure keys once

The input fields are secret and can be saved encrypted in an Apify Task. For a reusable Actor configuration, set a secret environment variable once in Apify Console under Source → Environment variables and leave the corresponding input field blank.

Use one of these names:

Selected provider	Secret variable
OpenAI	OPENAI_API_KEY
OpenRouter	OPENROUTER_API_KEY
Anthropic	ANTHROPIC_API_KEY
Gemini	GEMINI_API_KEY
DeepSeek	DEEPSEEK_API_KEY
Mistral	MISTRAL_API_KEY
Groq	GROQ_API_KEY
ZenMux	ZENMUX_API_KEY
xAI	XAI_API_KEY
Qwen / Alibaba DashScope	QWEN_API_KEY
NVIDIA NIM	NVIDIA_API_KEY

For Tavily, set TAVILY_API_KEY. Mark every key as Secret. A value typed into the input overrides the environment variable for that run. Never put keys in source code, README files, datasets, or Docker build arguments.

Supported AI providers

The Actor supports direct adapters for OpenRouter, OpenAI, Anthropic Claude, Google Gemini, DeepSeek, Mistral, Groq, ZenMux, xAI Grok, Qwen / Alibaba DashScope, and NVIDIA NIM. The model field is passed through as an exact provider model ID, so the user can change models without code changes.

OpenRouter is the broadest option: one key reaches hundreds of model/provider combinations, including NVIDIA, Qwen, DeepSeek, and other vendors. Direct adapters are useful when you want the provider account, billing, rate limits, and data policy to be explicit. We do not claim that every provider on the internet has a dedicated adapter; for new OpenAI-compatible gateways, OpenRouter is the compatibility layer.

The default remains openrouter/free, which is useful for low-volume tests but has variable availability and tighter free-tier limits. For production, choose a pinned model such as openrouter/auto or an exact model ID and monitor cost, latency, and JSON reliability. Provider keys are marked secret in the Actor input schema and are never included in dataset output.

Provider/model examples

Goal	aiProvider	model	Secret
Lowest-friction test	openrouter	openrouter/free	OPENROUTER_API_KEY
OpenRouter automatic routing	openrouter	openrouter/auto	OPENROUTER_API_KEY
NVIDIA direct	nvidia	meta/llama-3.1-70b-instruct	NVIDIA_API_KEY
Qwen direct	qwen	qwen-flash	QWEN_API_KEY
DeepSeek direct	deepseek	deepseek-v4-flash	DEEPSEEK_API_KEY

Always keep the selected provider, model family, and secret aligned. If the model is blank, the Actor uses a safe provider default. The defaults track currently supported model IDs: Gemini gemini-3.5-flash, DeepSeek deepseek-v4-flash, Qwen qwen-flash, Groq openai/gpt-oss-120b, and NVIDIA meta/llama-3.1-70b-instruct. Provider catalogs change, so pin an exact model in production and retest after provider deprecation notices.

GitHub, dev.to, and open source

Open source is optional. For the Apify Store, the source can stay private while the Store page, README, examples, and a short demo explain the outcome. A public GitHub repository is useful for trust and copy-paste examples, but it does not need to contain the full implementation: publish a sanitized example input, output schema, architecture notes, and issue tracker if you prefer to keep the core Actor private.

For dev.to, publish a practical tutorial such as “From 100 company URLs to a ranked outreach list with evidence,” with a 30–90 second run video, one redacted output, the Apify Actor link, and a clear note that users bring their own keys. Do not commit API keys, customer leads, or private datasets. The technical Actor slug stays stable; the human-readable Store title can change without breaking integrations.

Reliability and security

• Public company URLs are validated before every request and redirect.
• Localhost, private networks, cloud metadata, embedded credentials, non-web schemes, and nonstandard ports are rejected.
• Responses are limited by content type, redirect count, and byte size.
• Website/search content is explicitly treated as untrusted data to reduce prompt-injection risk.
• Fabricated evidence chunk IDs cannot support a score.
• Unconfigured criteria and disqualifiers cannot affect scores.
• Failed leads produce transparent failed dataset items without charging a success event.
• Concurrency is bounded from 1 to 10.
• Pay-per-event runs preflight the user’s charge limit and stop output when it is reached.

Limitations

• A model can still misinterpret ambiguous evidence. Review high-value prospects manually.
• Standard verification uses one LLM judgment pass; choose deep for higher-stakes lists.
• Static HTTP extraction may miss JavaScript-rendered websites.
• Public pages can be outdated or incomplete.
• The Actor generates drafts; it does not send LinkedIn messages or email.
• Do not use the output for protected-trait profiling or automated high-impact decisions.

Local development

Requires Python 3.11+.

pip install -r requirements.txt
python -m unittest discover -s tests -v
apify run

To simulate pay-per-event locally:

$ACTOR_TEST_PAY_PER_EVENT=true apify run

Deploy with:

$apify push

Before publishing, configure the default dataset item event (shown as lead in the pricing UI) in Apify Console. The code follows the official Apify pay-per-event flow, including charge-limit checks.

Version 0.3 migration

Version 0.3 keeps the 0.2 input/output contract and adds:

• provider-specific secret environment-variable fallback;
• Tavily environment-variable fallback;
• no silent switching from OpenRouter to ZenMux when a legacy zenmux: model is present;
• OpenRouter’s default model is openrouter/free when the model field is blank; use openrouter/auto explicitly when the account has credits.

Clear any old zenmux: model from saved Tasks and republish the Actor before testing again.