The Contact Enrichment Waterfall — Verified Decision-Makers Without Burning Credits

Contacts Are a Budget Problem Wearing a Data Costume

Every field in a company record is cheap to collect except one. Addresses, revenue estimates, product categories — scrapable, inferable, free. The name and verified email of the person who signs purchase orders? That costs money, per person, every time, from every vendor. Which means contact enrichment isn't really a data engineering problem — it's a budget allocation problem with an API attached. The naive design — "enrich everything" — spends the same credit on your best-fit prospect and on a company you'd never call.

In the market intelligence platform this architecture comes from, the store tracks 19,100 companies, but only about 2,800 have had contacts revealed through paid APIs. That gap is not a shortfall. It's the entire design.

Score First, Enrich Second

The pipeline's ordering rule: scoring runs before enrichment spends. Every company gets scored against the ideal customer profile using the free fields — product fit, revenue band, company type — and only companies that score into qualified tiers are eligible for paid contact discovery. Everything below the line waits until some other signal promotes it.

This sounds obvious. Almost nobody builds it this way, because scoring and enrichment usually live in different tools owned by different teams, and the CRM happily bulk-enriches whatever list it's handed. Putting both stages in one pipeline is what makes the ordering enforceable: the enrichment job literally queries for qualified tiers and ignores the rest.

The Waterfall: Cheapest Source First

Eligible companies descend a waterfall ordered strictly by cost:

The company's own website — free. An extraction pass finds the company's homepage (with an LLM confirmation gate: if the model isn't at least 70% confident this is really the company's site, the match is withheld rather than guessed), then reads the contact and team pages under a robots.txt-honoring fetcher and extracts named people with an extract-don't-invent prompt. Emails found this way rank below API-verified ones — but they're free, and for small companies they're often the only contacts that exist anywhere.
Credit-gated API reveal — one credit, once. For companies that still lack a decision-maker, one Apollo people search runs against a ranked list of fifteen buyer-role titles — plant manager, engineering manager, operations manager, maintenance manager, and so on, weighted in four tiers by how close the role sits to the purchase decision. The top-ranked person gets revealed: exactly one search and at most one paid reveal per company. Not five reveals hoping one email verifies — one, chosen by title rank, because the second-best contact at a qualified company is worth less than the best contact at the next company in the queue.
Premium per-collect sources — twenty credits, human-triggered. Some data vendors charge an order of magnitude more per record. Those sit behind the UI only — deliberately no bulk CLI, so a 20-credit collect requires a human clicking on a specific person at a specific company. You cannot accidentally loop it over ten thousand rows, because the loop doesn't exist.

The No-Double-Spend Rules

The waterfall's economics only hold if the pipeline can never pay twice for the same answer. Three rules, all enforced in code rather than convention:

Provenance is the spend ledger. Every enrichment result writes a provenance row naming its source. Before any paid search, the pipeline checks: does this company — or this domain — already have a row from this source? If yes, skip. Re-running an enrichment job after a crash re-spends nothing, because the ledger already shows what was bought. Resume-safety isn't a nice-to-have here; it's the difference between an idempotent pipeline and an invoice surprise.

Related-domain short-circuit. Companies in the same corporate family often share contacts. If a sister company under a related domain already has revealed contacts, the search is skipped — the entity resolution layer knows they're related, so the enrichment layer gets that knowledge for free.

Bank the entire payload. A reveal returns far more than an email — thirty-plus fields on the person, a fifty-field organization profile. All of it is stored raw. When someone later opens that contact in the portal, the full vendor record renders from storage — 6,041 already-paid payloads re-displayable at zero incremental cost. Paying per reveal and then discarding nine-tenths of the response is the quietest way teams double their enrichment bill.

Verification: Status Only Moves Up

Contact quality decays in transit through a pipeline unless you make decay impossible. Emails carry a status — gated, unverified, valid — and the rule is upward-only: a later source re-asserting an email can never demote a status an earlier verification earned. Combined with person-level dedup (merge on name + title, or email, or phone), the store converges: 37,504 contact rows, 5,641 of them carrying a verified valid email, and no run of any job can silently un-verify one.

Close the Loop: Contactability Caps the Score

The last piece runs backwards — enrichment feeds scoring. A company with no verified decision-maker email has its score hard-capped just below the top tier, no matter how perfect the fit looks on paper. The reasoning: a lead your team cannot reach isn't a top-tier lead yet — it's a research task. The cap makes that visible in the tier itself instead of letting un-contactable companies clog the call queue. The first enrichment sweep over top-tier companies made the effect concrete: 51 contacts pulled, 46 verified emails — and the five companies whose emails failed verification dropped out of the top tier automatically, replaced by companies a rep could actually call that morning.

The Shape Generalizes

None of this is specific to sales contacts. Any pipeline that pays per API call — geocoding, company firmographics, identity verification, LLM calls — wants the same skeleton: qualify before you spend, order sources by cost, keep a provenance ledger that doubles as a spend ledger, make re-runs free, store full responses, and never let cheap data overwrite expensive verification. The API integration service page covers how I build these; the case study shows this one live, and the buying-signals article covers what happens after you know who to call — figuring out when.