The conversation that led to this project started with a simple frustration: we are always finding out about things too late.
A target company raises a Series B. We find out when a competitor announces they won the deal. A VP of Marketing joins a company we have been tracking. We find out when they post about it three weeks later. An engineering team triples in size, signalling a scaling moment. We find out when the annual report comes out.
The signals were there. We were just not watching in the right places at the right time.
This is the promise of AI company scouting: the system watches for you, and surfaces what matters when it matters. Getting there turned out to be a very different problem than the one we started with.
Why more signals make AI company scouting worse
The obvious answer is: watch more signals. Set up Google Alerts. Monitor LinkedIn. Subscribe to Crunchbase. Track job postings.
This is what most companies try first. It does not work, not because the signals are not there, but because the signal-to-noise ratio collapses immediately.
If you are tracking 500 companies across four signal sources, you are processing 2,000+ updates per day. Most of them are irrelevant. Some of them are relevant but low priority. A handful are high-priority moments that require action this week.
Separating those three categories manually takes more time than just doing the prospecting by hand.
The real problem: entity resolution
When we started designing the scouting system, we spent three weeks on signal ingestion and scoring before realising we had skipped the hard part.
The hard part is entity resolution.
A signal arrives: “Acme Technologies raises $40M Series B.” Another signal arrives: “Acme Tech announces expansion to APAC.” A third signal: “Head of Revenue Operations, Acme Technologies, posted a new job.”
These are three signals about the same company. Unless the system knows they are the same company, it processes them as three separate events with low individual signal strength. The insight that Acme Technologies is in an aggressive growth phase, expanding geographically and building out the revenue org, only exists if you can connect all three.
Connecting them is harder than it looks. Company names are not standardised.
LinkedIn says “Acme Technologies.” Crunchbase says “Acme Tech.” The job board says “Acme Technologies, Inc.” A news article says just “Acme.”
These all need to resolve to the same entity before any scoring can happen.
We built the entity resolution layer before touching the scoring logic. Domain matching, fuzzy name matching, funding round ID correlation, and a confidence threshold below which we flagged for human review. It took four weeks. It is not the interesting part of the system. It is the part the system depends on entirely.
What good scouting looks like at steady state
At steady state, the system monitors 12 signal sources and surfaces 40 to 80 qualified company prospects per week. Each one arrives in the CRM with the specific signal cluster that triggered it: what signals fired, when, with what confidence.
Reps do not receive a list of companies. They receive a list of companies with a reason. “Three senior engineering hires in 90 days plus a new Head of Revenue Operations” is a different brief than “posted a positive product review.” Both are interesting. They require different outreach.
The ICP matching layer uses an AI model loaded with the client’s specific criteria: company size range, funding stage, technology signals, geographic focus. It evaluates each resolved signal cluster and generates a one-paragraph rationale for every qualified match. Reps can disagree with the rationale and mark it as a miss. That feedback improves the matching over time.
The lesson
Signal-based scouting is primarily an infrastructure problem, not an AI problem. The AI handles the last 20% of the work: evaluating fit, generating rationales, handling ambiguous cases. The first 80% is data pipeline: sourcing signals reliably, normalising them, and resolving them to consistent entities.
If you skip that 80% and go straight to the AI layer, you get a system that produces impressive-looking output from noisy, inconsistent input. That output will look good in a demo and fail in production. Most sales intelligence automation projects fail at exactly this step, not because the AI was wrong, but because the plumbing underneath was never built.
Build the entity resolution first. Then the scoring. Then the AI layer.
The full technical architecture is in the Signal-Based Company Prospect Intelligence Engine case study. If you are working on something similar, let’s talk.