Waterfall Enrichment: How to Sequence Providers Without Wasting Credits

No single provider covers your signups

Every enrichment provider has a coverage gap. One is strong on funded startups and weak on bootstrapped SMBs. Another has deep LinkedIn data but chokes on personal email domains. A third nails company firmographics but returns nothing useful for the person. Wire your signup flow to one API and call it done, and you'll end up with a chunk of users (often 30% or more) sitting there unresolved. You won't even know if that's because the data doesn't exist or because you only asked one place.

Waterfall enrichment is the answer most mature data teams land on: query providers in a defined order, stop as soon as you have a confident match, and only pay for the next call when the current one comes up short. Done well, it raises match rates without blowing up your enrichment bill. Done badly, it's an unmaintained pile of API keys and someone's memory of why provider three comes before provider four.

This post is about building that sequence deliberately: the order, the thresholds, the spend controls, and the operational habits that keep it from rotting. Groful runs an agentic version of this internally. It chains search, contact database, and LinkedIn lookups per signup instead of a fixed provider order, but the underlying logic is the same one you'd apply to any PLG signup enrichment stack.

What a waterfall actually is

A waterfall is a sequence of enrichment calls, each one a fallback for the last. The signup comes in, you check the cheapest and most likely-to-succeed source first, and if it returns a confident match you stop there. If it doesn't, you escalate to the next source, which is usually more expensive, slower, or narrower in what it covers. You keep escalating until you get a good answer or run out of sources worth trying.

This is different from calling every provider at once and picking the best response. Calling everything in parallel is faster and simpler to reason about, but it means paying for four API calls on signups where the first one would have worked fine. A waterfall trades a bit of latency for meaningfully lower cost per resolved user, which matters once you're enriching thousands of signups a month.

Why a flat, single-provider setup falls short

Say your product signs up a mix of funded B2B SaaS buyers, solo freelancers, and enterprise IT admins using their corporate email. A firmographic database with strong funding and headcount data will nail the funded SaaS buyer and probably miss the freelancer entirely, because there's no company record to attach a personal email to. A reverse-email resolution service will catch more of the personal-email cases but often can't tell you the person's job title with any confidence. Neither one, alone, gets you where you need to be.

Stack them, and the pattern flips. The company-database provider handles the segment it's built for. Anything it can't resolve, mostly personal or ambiguous domains, falls through to a provider built for exactly that case, something closer to personal email enrichment. What's left after both is a smaller, genuinely hard set: shell companies, disposable domains, and signups with too little signal to work with regardless of who you ask.

Designing the sequence

The order of your waterfall is the whole design decision. Get it wrong and you either overpay or underperform. Three principles do most of the work.

Put the cheapest, highest-confidence source first

Rank your candidate providers by a rough score of (expected match rate for your traffic) divided by (cost per call). The source that wins that ratio goes first, not the source with the best marketing page. If your users are mostly B2B SaaS employees on work email, a firmographic lookup by domain is usually cheap and reliable, so it goes first. If your traffic skews personal-email heavy, that same lookup will miss constantly and should move down the list.

Escalate only on a real miss, not a soft one

Define what counts as a hit before you build the sequence. A hit isn't "the API returned something." It's "the API returned a company match with a specific confidence floor" or "returned a named person, not just a domain guess." Anything below that bar should be treated as a miss and pushed to the next provider, even if the first call technically succeeded. This is the single most common failure mode in waterfall builds: teams accept a low-confidence first hit because building the escalation logic felt like more work, and end up with a database full of shaky company matches nobody trusts.

Cap spend per record

Set a hard limit on how many providers a single signup can pass through, and a rough credit ceiling per user. Without a cap, a stubborn signup with an unusual domain can trigger four or five paid calls chasing a match that was never going to resolve. Two or three providers deep is usually enough. Past that, route to manual review or accept partial data instead of continuing to spend.

Confidence thresholds: the part people skip

A waterfall without confidence scoring is just an expensive retry loop. Every provider in the chain should return, or let you derive, a confidence signal: exact domain match versus fuzzy name match, verified employment versus inferred from a public profile, and so on. Set your escalation threshold explicitly per stage:

• Stage 1 (cheapest source): escalate if confidence is below your minimum bar, or if the response is empty.
• Stage 2 (broader source): escalate again only if confidence is still low, not just different from stage 1.
• Stage 3 (specialist source, e.g., reverse email or agentic lookup): accept the best available answer, flag low-confidence results for review instead of writing them as fact.

Store the confidence score and the winning provider alongside the enrichment result. When something looks wrong three months from now, you want to know instantly whether it came from a high-trust source or a last-resort guess.

A five-step operational playbook

1. Segment your traffic first. Pull a sample of recent signups and bucket them by domain type: corporate, personal, disposable, unknown. Your waterfall order should follow this mix, not an assumption about who signs up.

2. Map each provider to the segment it actually wins. Test each candidate provider against the same sample and record match rate and average confidence per segment, not an overall blended number. A provider that looks mediocre overall might be the best option for one specific segment.

3. Order the sequence by cost-adjusted match rate. Cheapest and most accurate for the largest segment goes first. Narrower, pricier, or slower providers go later, reserved for what earlier stages can't touch.

4. Set thresholds and caps before you go live, using the rules above. Write them down somewhere your team can find them later: a wiki page, a config file with comments, anything but institutional memory.

5. Route unresolved records deliberately. Signups that exhaust the waterfall without a confident match shouldn't just disappear into an "unknown" bucket forever. Send them to a lightweight review queue, retry on a schedule as providers update their data, or route them into onboarding without personalization instead of guessing.

Metrics that tell you the waterfall is working

Track these at the sequence level, not just per provider:

• Overall match rate, and match rate by segment (corporate, personal, disposable).
• Percentage of matches resolved at stage 1 versus stage 2 versus stage 3, which tells you if your ordering is right.
• Average cost per resolved signup, compared against a single-provider baseline.
• Confidence distribution of accepted matches, so you can spot drift toward more low-confidence acceptances over time.
• False-positive rate caught downstream, whether that's a sales rep flagging a wrong company or a support ticket about a mismatched name.

If stage 1 is resolving fewer signups than it used to, your traffic mix has probably shifted and your ordering needs a review. If cost per resolved signup is climbing without a matching rise in match rate, something downstream is escalating too eagerly.

Common mistakes

The most common one is building the sequence once and never revisiting it. Provider coverage changes, your traffic mix changes as you enter new markets, and a waterfall tuned for last year's signups quietly gets worse every month nobody looks at it.

The second is accepting a technical success as a real match. An API returning HTTP 200 with a plausible-looking company name is not the same as a verified match, and treating them the same is how you end up shipping enrichment confidence and false-positive problems downstream into sales and product personalization.

The third is calling every provider for every signup out of caution. It feels safer, but it triples your bill for a marginal accuracy gain on the segment your first-stage provider already handles well.

The fourth is having no owner. A waterfall touches procurement, engineering, and growth all at once, and if nobody owns the sequence end to end, it drifts until someone notices the enrichment budget doubled without anyone deciding that should happen.

Checklist: auditing your waterfall

• List every provider currently in your enrichment stack and the order they're called in.
• Confirm that order was chosen deliberately, not by whichever integration got built first.
• Check that each stage has an explicit confidence threshold, not just a "did it respond" check.
• Verify there's a hard cap on providers-per-record and dollars-per-record.
• Pull match rate and cost per resolved signup for the last 90 days, broken out by segment.
• Identify the segment with the lowest match rate and test whether a different provider order would help.
• Confirm someone owns this sequence and reviews it at least quarterly.

Where this fits in the bigger picture

Waterfall design is infrastructure, not a growth tactic on its own. It's the infrastructure everything else depends on. ICP scoring is only as good as the company data feeding it. Teammate discovery only finds people at companies you resolved correctly in the first place. Lookalike search needs clean seed accounts to work from. If you're evaluating enrichment providers or trying to fix a stalled match rate, start by auditing the sequence before you add another vendor to the stack.

Groful runs this as an agentic pipeline rather than a fixed provider order, so it can skip stages that won't help a given signup and go straight to the source most likely to resolve it. If you want to see how that compares to building and maintaining a waterfall yourself, get in touch or browse more enrichment playbooks.