Waterfall Enrichment: Finish the Free Steps First

What is waterfall enrichment, and why does the order matter?

Waterfall enrichment resolves a missing data point by trying sources in a fixed sequence rather than all at once, stopping at the first source that answers. The order is by cost, cheapest first. Done properly, most records are resolved before any paid provider is called, and the paid budget covers only the genuinely hard remainder.

The alternative, which is what most teams actually run, is to point one paid provider at the whole list and accept the invoice. That works, and it is expensive in a way that never shows up as a line item: you pay for records you already had, for duplicates of the same company, and for values a free derivation would have produced in seconds.

The sequence below is the one we run at SalesPlaybook on multi-source account lists. It is not the only valid order, but the principle behind it is not negotiable: no credit is spent on a record until every free step has had its turn.

Which enrichment steps cost nothing, and why do they run first?

Three of them, and they routinely resolve the majority of a list. Derive the company domain from an email address where a source carries one. Scrub junk domains that are not companies. Then let records without a domain adopt one by exact name match. All three are deterministic, instant, and free.

Step one has a trap worth naming. A free-provider domain recurs across many unrelated company names, while a real company domain recurs only across its own offices. So the blocklist alone is not enough: a distinct-name frequency check catches the providers a static list has not heard of yet.

Step three is the one most teams skip, and it is free money. In a list assembled from several sources, the same company frequently appears once with a domain and once without. Matching on the normalised name closes that gap at zero cost, as long as the match is unambiguous. Exactly one candidate, or no adoption.

How quickly does enriched B2B data go stale?

Fast enough that enrichment is a recurring process, not a project. Roughly a fifth of a B2B database becomes unreliable within a year, and email addresses decay faster than company records. That is the number that decides how often the cascade has to run, and it is the argument for making the free steps repeatable.

The decay figures put a clock on the whole exercise. Datamagnet's 2026 compilation, drawing on HubSpot's database-decay work, reports that a typical B2B contact database loses 2.1% of its records a month, compounding to roughly 22.5% a year, with cumulative decay passing 12.0% at month six. On the email side it cites ZeroBounce: 23% of addresses in a typical list go bad every year, down slightly from 28% in 2024. Set that against the deliverability ceiling Mailshake reports, where hard bounces should sit below 0.5% and a total bounce rate under 1% is described as the minimum expectation rather than an aspiration, and the arithmetic is uncomfortable. Cumulative decay reaches 6.2% at month three and 17.4% at month nine on that same curve, so the difference between a quarterly refresh and an annual one is not a matter of taste. A list enriched once and reused for a year cannot hold that ceiling. The cascade is worth building precisely because it is cheap enough to run again.

Where the sequence is in place, the effect shows up in booked meetings rather than in a cleaner spreadsheet. node.energy Generates 5x More Demos in Three Months Through Targeted Outbound With Clay Integrated Into HubSpot is the worked example from SalesPlaybook's own client list, and the enrichment layer is the part of it that did the unglamorous work.

Why must deduplication happen before you pay for enrichment?

Because paid enrichment bills per record, and a multi-source list contains the same company several times. Enrich first and you pay once per copy, then merge the results into a record whose field conflicts nobody can adjudicate. Deduplicate first and you pay once per company, on a row that survives the merge.

Which is why domain completion has to come before the merge rather than after it. The domain is the deduplication key. A list with 30% missing domains cannot be deduplicated properly no matter how good the merge logic is, because the rows that would have matched have nothing to match on. Free domain coverage first, then dedup, then credits.

What should an enrichment agent do when it cannot find a value?

Return empty. Never guess. This is one rule and it decides whether the whole dataset stays trustworthy, because the two failure modes are not symmetric: a blank field announces itself and can be filled at any later point, while a plausible wrong value passes every validation and quietly poisons everything downstream of it.

For domain recovery specifically, that means the agent returns the registrable domain and nothing else, or it returns nothing. Give it the strongest signal you have, ideally a company LinkedIn URL, otherwise the company name plus country plus something that disambiguates it, a city or a service they offer. In DACH the most reliable single query is the company name plus impressum, because the legal-notice page names the domain directly.

Then re-validate on write-back, against the same blocklist and domain-shape rules that governed the free steps. An agent result is an input, not an authority.

How do you prove a multi-source merge lost no records?

With one assertion you can run every time: the sum of merged-record counts across the deduplicated master must equal the row count of the full union. If those two numbers match, nothing was silently dropped. If they diverge, the merge is wrong and no downstream number can be trusted.

That is why we keep two masters rather than one. A FULL master retains every source record for traceability, and a DEDUPED master holds one row per company with its provenance attached: which source records merged into it, how many, and which fields conflicted. The assertion runs between them. Without it, a market size is a number someone believes rather than one anyone can check.

Keep the domain-name near-duplicates as a flagged review list rather than an automatic merge. TLD variants and shared platform domains look identical to a matcher and are frequently different companies. Flag, then let a person decide.

Which enriched fields are safe to base decisions on?

Only the ones whose origin you can name. Self-reported headcount, industry labels and company type arrive from scrapes and directories at wildly varying quality, so they belong in audit-only columns. A field that drives targeting or scoring needs a known, trusted provider behind it, not a value that merely looks plausible.

The practical rule is to quarantine untrusted firmographics on ingest, into separate columns marked as such, and never let them feed a filter or a score. Keep every original column from every source alongside them, so a later question can be answered without re-sourcing. Nothing gets deleted; things get labelled.

That discipline is what makes the rest of the pipeline defensible. If you build B2B pipeline generation on a list whose fields have known provenance, the targeting argument can be checked. The step before it carries just as much weight: the suppression check has to pass before any paid enrichment runs, and the count it leaves behind is what a pipeline generation plan is built on, in email and in LinkedIn GTM alike. Our AI outbound work sits on top of this layer rather than replacing it, and inside a HubSpot CRM setup the same rule applies to every property a workflow reads.