Claude Code Buying Signal Scanner
Detect job posts, funding, and tech changes. Score them. Route the urgent ones. Queue the rest.
What the Scanner Does
Companies broadcast their buying intent through five channels. They hire. They raise. They change tech. They reshuffle leadership. They publish about the problem. A buying signal scanner watches all five for your target accounts and surfaces the patterns worth acting on.
Without an automated scanner, your SDRs check job boards manually, miss most funding events, and read about leadership changes on LinkedIn weeks late. With a scanner, the same intel arrives in your CRM the morning after the signal fires, scored against your ICP rules.
For the underlying signal types and rationale, see the buying signal detection guide. This guide covers the Claude Code build.
Step 1: Pick the Source Set
Don't wire all five sources on day one. Start with the two that produce the highest signal for your business.
Job postings. Universal high-signal source. Use Greenhouse's open API, LinkedIn's job search (via Sales Navigator or a scraper), or a job-board aggregator. Filter by company (against your target account list), title keywords (roles your product supports), and posting date (last 14 days).
Funding events. Use Crunchbase's API, news APIs (NewsAPI or similar), or scrape TechCrunch/Axios funding announcements. Filter by date (last 90 days), round size (above your threshold), and company against your account list.
Add the next three sources after the first two are tuned and producing usable signal: technographic changes, leadership changes, content signals.
Step 2: Wire the MCP Servers
For each source, wire an MCP server.
For job postings via Greenhouse:
claude mcp add --transport stdio greenhouse -- npx -y mcp-server-greenhouse
For Crunchbase:
claude mcp add --transport http crunchbase https://api.crunchbase.com/mcp --header "Authorization: Bearer $CB_TOKEN"
If a source doesn't have an MCP server, wrap its REST API in a small stdio server. The Anthropic SDK template handles the boilerplate in 40 lines of Python.
Step 3: Define the Scoring Logic
Each signal type gets a base score and modifiers. The scoring lives in a config file, not in the prompt, so you can adjust weights without touching the workflow logic.
Job posting base score. 5 points for a relevant role. Modifiers: +3 if posted in last 7 days, +2 if VP+ title, +2 if remote (often indicates expansion), -2 if posting more than 30 days old.
Funding base score. 7 points for any new round. Modifiers: +3 if Series B or later, +3 if size above $20M, +2 if announced in last 30 days. Funding signals decay fast (the window to engage closes 60 to 90 days post-announcement).
Tech change base score. 4 points for a competing product adoption, 6 points for a complementary product adoption. Modifiers: +2 if change confirmed via BuiltWith (vs. self-reported on a job post), -3 if change is older than 90 days.
Leadership change base score. 5 points for a new VP+ in revenue or a relevant function. Modifiers: +3 if from a known competitor or customer, +2 if move announced within 60 days.
The skill sums the scores across signals on the same account and routes based on total score.
Step 4: Write the Workflow Prompt
The scanner runs as a scheduled workflow. The prompt:
Role. "You are a buying signal scanner. You read raw signal data from MCP servers, score each signal against the rules in scoring.json, and write a structured signal record to the signals_queue table."
Steps. 1. Read the list of target accounts from the CRM (filter to accounts not closed or marked do-not-contact). 2. For each account, pull signals from the wired sources. 3. Score each signal. 4. Sum the score per account. 5. Write the result to the signals queue with: account_id, signal_type, signal_source, signal_score, signal_summary, detected_at, expiry_date. 6. If total account score is above the alert threshold, post to the AE's Slack channel.
Stopping conditions. Stop after processing 500 accounts. Stop on any error rate above 5%.
Step 5: Tune the Signal Rules
First-month accuracy is rough. Plan for tuning.
Each week, review the signals queue. For each signal that fired, mark whether it was actually useful (did it correlate with a meeting, a deal, or even just a meaningful conversation). For each useful signal you missed, identify the source and the rule that would have caught it.
Adjust the scoring weights based on the data. If "job posting for SDR role" never produced meetings, downgrade that signal weight. If "VP Sales hired from a known competitor" always produced meetings, upgrade that weight.
After three months of tuning, your scoring should match what your best AE would identify as a real signal. That's the goal.
Step 6: The Alert and Queue Pattern
Two channels for output. The queue. Every signal goes here regardless of score. The SDR or AE works the queue in priority order each morning. The alert. Only the top 5 to 10% of signals (score above a high threshold) trigger direct Slack DMs to the AE. The alert is for "drop what you're doing and act on this." The queue is for "work this when you have capacity."
This pattern prevents alert fatigue. If every signal triggered an alert, AEs would mute the channel within a week.
Step 7: Schedule and Monitor
Schedule the scanner as a daily cron at 6 AM. The signal queue is populated by 7 AM. SDRs work the queue at 9 AM during stand-up.
Monitor three metrics weekly. Signal volume. Are we generating roughly the same number of signals each week? Big swings indicate a source change or a scoring drift. Conversion rate. What percentage of signals produce a meeting? This is the headline metric. Cost per signal. Track total monthly spend on enrichment, model tokens, and infrastructure. Divide by signal count. If cost per signal exceeds your target, optimize the most expensive source or cut it.
Where the Scanner Goes Wrong
Three failure modes. Stale signal data. The job posting was filled three weeks ago but still listed. Add a freshness check that confirms the posting is still active before scoring it. Noise from press release amplification. A funding round gets covered by 12 outlets and the scanner fires 12 signals on the same event. Dedupe by event signature (company + round_size + round_date). Signal whiplash on noisy accounts. Some accounts produce signals constantly (frequent funding, fast hiring). Cap signals per account per week to avoid SDR fatigue.
For the broader sales agent pattern, see the sales agent guide. For the underlying signal types, see the buying signal detection guide. For the agent fleet pattern when you scale to multiple scanners, see orchestrating a fleet of GTM AI agents.
Authoritative References
For Claude Code MCP setup, see Anthropic's MCP documentation. For Crunchbase's funding data API, see the Crunchbase API documentation.
Frequently Asked Questions
What signals does a Claude Code buying signal scanner actually look for?
Five signal categories matter most for B2B. Job postings for roles your product supports or complements. Funding events (new round announced within 90 days, IPO, acquisition). Tech stack changes (adoption or removal of competing products, integration signals). Leadership changes (new CRO, VP Sales, Head of GTM). Content signals (the company published or executives wrote about the problem your product solves). Each signal has different weight and decay. The scanner combines them into a score and a recommended action.
Where does the scanner pull signal data from?
Job posting boards (LinkedIn, Indeed, Greenhouse, company careers pages), funding databases (Crunchbase, news APIs), technographic vendors (BuiltWith, Wappalyzer, or Clay's tech stack enrichment), leadership change APIs (Pitchbook, LinkedIn's people-change endpoints), and direct web search for content signals. Most teams wire 3 to 5 sources rather than all of them, because each source adds cost and complexity. Start with job postings and funding since they're highest signal.
How often should the buying signal scanner run?
Daily for new accounts. Hourly for accounts already in an open opportunity (where new signals can move the deal). The frequency depends on how fast you act on the signal. If your SDR can't reach out within 24 hours of a signal firing, scanning more often than daily is wasted compute. Most teams run the scanner at 6 AM and SDRs work the signal queue starting at 9 AM.
What's the false positive rate on automated buying signals?
High without tuning. Out of the box, signal detectors fire on noise: a job post for a role you don't actually serve, a funding announcement that's a press release amplification, a tech stack change that's actually a documentation update. Expect 30 to 60% false positive rate on the first month of runs. After three months of tuning the rules and adjusting weights based on which signals actually predicted meetings, the false positive rate drops to 10 to 20%. Plan for the tuning period.
Should the scanner alert the AE directly or route through a queue?
Queue first, alert only for highest-tier signals. A scanner that pings every AE on every signal is noise that AEs ignore. The pattern that works: write every detected signal to a queue (Notion database, Airtable, or a Slack channel). Send direct AE alerts only when score is above a high threshold (top 5 to 10% of signals). The queue handles the long tail. The alert handles the urgent.
Source: State of GTM Engineering Report 2026 (n=228). Salary data combines survey responses from 228 GTM Engineers across 32 countries with analysis of 3,342 job postings.