How to Route Enrichment So It Learns from Every Call

TL;DR — Waterfall enrichment sequences multiple data vendors under the assumption that vendor A is cheaper and good enough for most records. In practice, a single rigid sequence burns credits on providers that guess wrong for your ICP and wastes rep time on calls that never connect. Instead of building a static waterfall, route enrichment dynamically and grade the result on the dialer: the call tells you which provider actually had the right phone number.

How waterfall enrichment actually works

Teams stitch together a chain: free sources like Apollo or Lusha for basic fields, then Zoominfo or Cognism for gaps, then a premium contact finder for high-value roles. The logic is intuitive — burn the cheapest credits first — and it keeps per-record enrichment cost predictable.

The problem is that “cheapest first” assumes all records are equally served by the first provider. In a single ICP, the first provider might have accurate mobile numbers for some contacts, outdated data for many, and nothing for others. The waterfall still queries it first for every single record. The outdated data goes straight to the dialer, where it costs rep time, not just credits.

Where the waterfall breaks

When a rep dials a number from provider A and gets a wrong number, the CRM usually doesn’t record why the number was bad. The enrichment pipeline never learns. Next week, a new list hits the same waterfall and the same provider gets queried first again for a nearly identical cohort.

The real cost isn’t in enrichment credits; it’s in dialer connections. A rep who spends a material chunk of a calling session on voicemails and wrong numbers misses live conversations that would have been had with better data.

The call as a grading mechanism

The only reliable signal of enrichment quality is what happens when a rep dials the number. Every connect, every “wrong number,” every “they left six months ago” is a verdict on the provider that supplied that contact.

A routing system that captures those verdicts and uses them to adjust provider weight per ICP — per segment — turns enrichment from a cost-savings exercise into a connection-volume exercise. The cheapest provider isn’t the one with the lowest per-record price; it’s the one that produces the most live conversations for the credits spent.

Why static falls apart at scale

The data market shifts. A provider that had solid UK coverage last quarter loses a source and their London numbers degrade. A waterfall built in a Clay table in March is blind to that by May. The RevOps hire who built it has moved on, and nobody else knows why the sequence was ordered that way.

Clay pioneered the idea that routing between providers matters, and a team with a dedicated GTM engineer can absolutely build a dynamic waterfall. Most outbound teams cannot hire that person, and even when they do, they are maintaining routing logic rather than working on pipeline.

When a fixed waterfall makes sense

If your team calls exclusively into a single ICP and you have validated — over multiple quarters — that one vendor’s phone numbers connect at a consistently high rate for that ICP, a waterfall is overhead. Query one provider and move on. The problem isn’t waterfall enrichment as a technique; it’s that teams adopt it as a default before they’ve measured whether any provider in the chain actually deserves to be first.

For a side-by-side of the platforms that run these waterfalls — what each charges, and what the published rate leaves out — see Clay alternatives.