DEEP DIVE · SIGNAL-BASED OUTBOUND

Job Posting Bot

When a target company posts a job for the exact role our product helps, they're feeling the pain right now. This bot finds the posting, figures out who's behind the hire, drafts the outreach with AI, and never sends anything a human didn't approve.

production · Vercel TypeScript Postgres Sumble / Crustdata HubSpot Slack review cards Claude Sonnet Lemlist adapter
The Signal

Hiring is the highest-intent public signal

A company hiring a Head of SEO or Content Lead is publicly announcing a budget, a pain, and a timeline. The problem is scale: you can't have SDRs manually scanning job boards for a few thousand Tier 1–2 accounts. And you can't blind-blast either, the person who cares about the posting is a specific hiring committee, not info@.

So the pipeline is: watch the accounts we already care about → detect relevant roles → infer who owns the hire → let a human approve AI-drafted outreach.

flowchart TD
  CRON[Weekday cron 12:00 UTC] --> HS[Load Tier 1–2 ICP companies
from HubSpot] HS --> MAP[Resolve domains → provider org IDs
cached once, never re-paid] MAP --> POLL[Poll job postings
low limits + local ICP-title filter] POLL --> DEDUP[(Dedupe by provider + job_id
in Postgres)] DEDUP --> COMM[Infer hiring committee
ranked stakeholder candidates] COMM --> SLACK[Slack card: job + HubSpot link
+ committee members] SLACK --> REVIEW[Signed review page
GET never mutates] REVIEW --> GATE{Human confirms?} GATE -->|No| DONE[Nothing sent] GATE -->|Yes| RECHECK[Re-check HubSpot
lifecycle + open deals] RECHECK --> EMAILRES[Email waterfall:
Apollo → LeadMagic → provider
validate all, BounceBan tie-break] EMAILRES --> AI[Claude drafts pain hypothesis
shown in editable approval form] AI --> CONFIRM{Explicit POST
confirmation} CONFIRM -->|Yes| ENROLL[Enroll in per-SDR
Lemlist campaign]
Engineering Judgment

The vendor decision was tested, not guessed

The obvious build was "ask the data vendor for every job posting at every target company." Live testing killed that: with strict filters it missed almost everything, and with loose filters it burned money on irrelevant postings. But the same vendor turned out to be genuinely good at a narrower job: once a relevant posting is already known, it could identify who inside the company was likely behind the hire. In a test on 10 known postings, it produced a plausible decision-maker on 9 of them.

So the system uses each vendor for what it's actually good at: one source for discovering postings, the other for identifying the people behind them, with the connection built so either vendor can be swapped out without rebuilding anything. Two other vendors were evaluated and documented as alternates, with their specific gaps noted.

Why this matters to a hiring manager
Most GTM automation dies from vendor lock-in to whichever tool was demoed first. This system tested vendors with live data before committing, documented the results, and kept them swappable, so changing data providers is a settings change, not a rewrite.
Safety Model

Layered gates before a single email sends

flowchart LR
  subgraph Detection["Detection (automated)"]
    D1[ICP company filter] --> D2[Role relevance filter] --> D3[Dedupe]
  end
  subgraph Judgment["Judgment (human)"]
    J1[Slack review] --> J2[Signed page confirm] --> J3[Edit AI draft]
  end
  subgraph Execution["Execution (gated)"]
    E1[CRM re-check] --> E2[Email verify waterfall] --> E3[Per-SDR campaign enroll]
  end
  Detection --> Judgment --> Execution
    
"The end-to-end test enrolled exactly one verified stakeholder into a draft campaign that physically cannot send until copy review. That's the posture: prove the pipeline works while making premature sending impossible."

Want systems like these at your org?

Contact Me 727-637-2778