The Phone Enrichment Waterfall: How to Stack Providers to Hit 85%+ Mobile Direct Dial Coverage

I ran our SDR team's call list through Cognism alone for six months. Hit rate on mobile direct dials: 34%. Then I built a 4-provider waterfall. Same list type, same ICP, three months later: 81%.

That 47-point gap is money. At 50 dials per day per rep, the difference between 34% and 81% connect-readiness means your team either leaves messages for ghosts or actually talks to people.

The frustrating part? Every article comparing phone enrichment tools treats them as alternatives. You pick one. But that framing is wrong — these databases don't overlap the way you'd expect, and stacking them in the right order is what actually moves the number.

Why a Single Provider Caps Out

Every phone data provider has coverage sweet spots:

• Cognism's Diamond Data is strong in EMEA and human-verified — but US SMB coverage is thinner than the pitch deck suggests
• Apollo covers US companies well, especially tech and SaaS, but mobile numbers (vs. direct dials) degrade fast outside major metros
• Lusha is consistently good for VP-level and above in North America; hit rate drops sharply below director title
• People Data Labs (PDL) has the deepest raw record count but ships whatever's in the database — verified or not

None of them is lying. They have different coverage shapes. When you run one provider against 500 contacts, you're leaving the other 60-65% of reachable records blank.

The Cascade Architecture (Order Matters)

The sequence in which you query providers is not arbitrary. Get it wrong and you're burning credits on a provider that would have caught the record anyway with a cheaper call.

Here's the ordering I landed on after testing across ~3,000 contacts over four months:

Tier 1: Cognism Diamond
Query first for any contact in EMEA or senior IC/director+ roles at companies over 200 employees. Cognism's human-verified numbers have a materially lower wrong-number rate than unverified databases — you pay more per credit, but you waste fewer dials on dead numbers.

Tier 2: Apollo
Fire next for any contact where Cognism returned nothing, plus all US-based contacts regardless of Cognism's result. Apollo's coverage of US SMB and mid-market is strong, and at its price point you can afford to check it broadly.

Tier 3: Lusha
Run on any VP-and-above contact where neither Tier 1 nor Tier 2 returned a mobile number. Lusha tends to have distinct sourcing from Apollo for senior titles — it regularly surfaces numbers Apollo misses at the C-suite level.

Tier 4: PDL as Fallback
PDL's bulk API is cheap per lookup. Use it as a final pass on everything that fell through. Treat any PDL-sourced number as unverified and route it to a validation step before dialing.

What Triggers the Next Provider (Cutoff Logic)

The cascade only fires the next tier when the current one returns nothing or returns a number flagged as low-confidence. Here's the decision logic:

IF cognism_phone IS NOT NULL AND cognism_verified = true → STOP
ELSE IF apollo_phone IS NOT NULL → STOP
ELSE IF lusha_phone IS NOT NULL AND seniority >= 'VP' → STOP
ELSE → pdl_phone (mark as unverified, route to validation)

Two things that matter here:

Don't short-circuit to the cheapest provider first. I tried starting with PDL to minimize upfront credit spend. The problem: lower-precision providers produce more wrong numbers, so your reps burn dial attempts on ghosts. The cost of a wasted dial (rep time, sequence disruption, prospect impression) is higher than the credit cost delta between Cognism and Apollo.

Validate PDL numbers before they reach a dialer. ZeroBounce and NeverBounce both do phone validation. ZeroBounce is cheaper per unit for batch runs. Route all PDL-sourced numbers through a validation step — bad numbers from an unverified database will tank your connect rate and flag your caller ID as spam faster than you'd expect.

The Cost Math Nobody Publishes

Here's what the cascade actually costs per found number at realistic hit rates from our data:

Provider	Cost/lookup	Hit rate (our data)	Cost/found number
Cognism Diamond	~$0.45	38% of total list	~$1.18
Apollo	~$0.08	29% of remaining	~$0.28
Lusha	~$0.18	22% of remaining VP+	~$0.82
PDL	~$0.02	14% of remaining	~$0.14

Running all four tiers on 1,000 contacts:

• Cognism (all 1,000): $450 → 380 numbers found
• Apollo (remaining 620): $49.60 → 180 more numbers
• Lusha (VP+ subset of remaining ~220, so ~80 contacts): $14.40 → 18 more numbers
• PDL (remaining 422): $8.44 → 59 more numbers (pre-validation)

Total: ~$522 for ~637 numbers → $0.82 per found number

Apollo alone on 1,000 contacts: ~$80 for ~290 numbers → $0.28 per found number.

Apollo is cheaper per found number. So why use the waterfall?

Because the 637 numbers from the waterfall cover contacts Apollo never would have found at all. The 347 additional numbers you surface via Cognism, Lusha, and PDL exist nowhere in Apollo's database. Coverage is the point — you're not replacing Apollo, you're filling in the 71% it misses.

Building the Waterfall in Clay

Clay makes this genuinely straightforward. The setup:

1. Create a Table, import your contact list
2. Add enrichment column → select Cognism; condition: run only if phone_number is empty
3. Add another enrichment column → select Apollo → condition: run only if previous column is empty
4. Add Lusha column → condition: previous empty AND seniority ∈ {VP, SVP, C-suite}
5. Add PDL column → condition: previous still empty
6. Add a phone_validated column using ZeroBounce integration, filtered to PDL-sourced rows only

The critical Clay setting: in each enrichment step, check "Only run if previous column is empty." This is what creates the cascade instead of running all four providers in parallel — which would multiply your credit spend by 4x with no coverage benefit.

Export cadence: for lists under 500, I run the whole cascade at once. Above that, I batch in 200-row chunks to stay within Cognism's rate limits.

Building It in n8n

If you're on n8n, the same logic expressed as a branching workflow:

1. HTTP Request node → Cognism API phone lookup
2. IF node: cognism.phone is not empty → route to CRM push
3. HTTP Request node → Apollo API
4. IF node: apollo.phone is not empty → route to CRM push
5. HTTP Request node → Lusha API (filter: only if seniority ≥ VP)
6. IF node: lusha.phone is not empty → route to CRM push
7. HTTP Request node → PDL API
8. HTTP Request node → ZeroBounce validation (PDL numbers only)
9. Set node: tag phone source on each contact record

Tagging the source matters. After 30 days you'll have empirical data on which tier is hitting for which segment of your ICP — and you can adjust ordering or skip tiers accordingly. The cascade architecture I described is a starting point, not a permanent configuration.

Provider Coverage by Segment

Provider	EMEA	US SMB	US Enterprise	Verified	API	Approx. cost
Cognism	★★★★★	★★★	★★★★	Yes (Diamond)	Yes	$$$
Apollo	★★★	★★★★★	★★★★	Partial	Yes	$
Lusha	★★★	★★★	★★★★	Partial	Yes	$$
PDL	★★★	★★★★	★★★	No	Yes	$
RocketReach	★★★	★★★	★★★	No	Yes	$$
Wiza	★★	★★★★	★★★	Partial	Yes	$$

What I Actually Use

For most mid-market prospecting lists (US-heavy, SaaS/tech ICP, director-to-VP seniority), the Cognism → Apollo → Lusha → PDL stack in Clay consistently lands between 78-83% of contacts with at least one phone number. That's the range I've seen across different client lists over the past several months.

Honest caveat: that 81% opening number came from a list skewed toward US enterprise with high VP+ density — exactly where this stack performs best. For lists heavy on individual contributors in Europe, the hit rate drops to the high 50s unless you lead with Cognism more aggressively and accept the higher per-unit cost.

Wiza is worth testing if your contacts are LinkedIn-sourced — it pulls numbers at the point of LinkedIn profile lookup, which can catch records that have decayed in static databases. I haven't stacked it into a persistent waterfall yet, but it's worth a controlled test against your specific ICP.

For phone validation on PDL-sourced numbers, ZeroBounce is my default for batch runs. NeverBounce has a better UI but equivalent accuracy in my experience — pick based on your existing integrations.

The goal isn't 100% coverage — it doesn't exist. The goal is knowing your actual hit rate by tier so you can stop guessing why your connect rate is stuck and start tuning the variables you can control.