Why One Provider Is Never Enough
Outcome: a baseline measurement of your current contact coverage, and a written provider-order decision for the waterfall you build in lesson 02.
- Surface
- App and MCP server
- Level
- Beginner
- Uses
check_credits- Credits
- 0
- Prerequisite
- A list of 50–100 contacts you already have
Where contact data comes from
No provider has a table of everyone’s email address. Each one assembles a partial view from a different mechanism, and the mechanism determines who they are good at.
| Mechanism | Strong on | Weak on |
|---|---|---|
| Contributed address books | Anyone who has ever been emailed by a sales team | New hires, private-by-default markets |
| Pattern inference from verified samples | Companies with a consistent, discoverable format | Companies with mixed or randomized formats |
| Public web and filings | Founders, execs, published contacts, small businesses | Individual contributors at large firms |
| Partner and network data | Whatever that partner over-indexes on | Everything outside it |
Two consequences follow, and both are the whole reason waterfalls exist:
- Coverage is segment-shaped, not quality-shaped. A provider that returns 75% on US mid-market SaaS may return 30% on European manufacturing. Neither number is “the provider’s accuracy.”
- The gaps are only partly correlated. Providers built on different mechanisms miss different people, which is exactly what makes stacking them worth the money.
What a waterfall does
Call the cheapest source with the best odds first
Ordering matters because you stop as soon as you have an answer. Putting your highest-hit-rate source first means fewer rows ever reach the expensive fallbacks.
Stop on a hit
The row is done. Nothing downstream is called, nothing downstream is billed.
Fall through on a miss
Only the rows that failed continue to the next source. The population shrinks at every step, so the expensive providers only ever see the hard residue of your list.
This is why waterfall pricing is not the sum of its providers. You pay per result, not per attempt — see Credits — so a run against a well-covered segment resolves early and cheaply, and a run against a long tail costs more per row precisely because it is doing more work.
Sync GTM’s Find work email runs this internally. You do not assemble the provider list yourself — but you do decide when a waterfall is worth running at all, which fallbacks you add after it, and what you accept as a result. That is what the rest of the course is about.
Coverage is not accuracy
These are two different measurements and conflating them is the most expensive mistake in this course.
| Term | Question it answers | How it fails you |
|---|---|---|
| Hit rate | Did we get an address? | Counts guesses that will bounce |
| Verified rate | Is the address deliverable? | Catch-all domains return “accept-all”, which is not the same as valid |
| Reach rate | Did mail actually land? | Only measurable after you send |
A vendor comparison run on hit rate alone will reliably pick the provider that guesses most aggressively. Lesson 03 covers verification and the catch-all problem; lesson 07 turns all three into one comparable number.
Take your baseline now
Before spending anything, measure what you already have. Every improvement later is judged against this.
- Take a real list of 50–100 contacts from your current motion — not your best segment, a representative one.
- Count how many have an email at all. That is your current hit rate.
- Count how many have been verified in the last 90 days. That is your current verified rate — for most teams starting this course, it is zero.
- Note which segment the list represents: geography, company size, industry. Coverage claims are meaningless without it.
- Ask your MCP client to run
check_credits, or open Credits, and write down the balance.
Write the five numbers down. Lesson 02 runs the same list through a waterfall and compares.
Choosing your fallback order
For lesson 02 you need one decision: what happens to the rows the work email waterfall misses. The answer depends on your motion, not on a general best practice.
| If your motion is | Miss behavior | Why |
|---|---|---|
| Cold email at volume | Drop the row | An unreachable row costs list quality and deliverability if you guess |
| High-value named accounts | Fall through to phone, then LinkedIn | The account justifies a second channel |
| Founder-led or SMB | Fall through to personal email | Small businesses often have no discoverable work address |
| CRM repair | Leave blank and flag | A wrong value is worse than a missing one in a system of record |
Write your answer down. It determines which of lessons 04, 05 and 06 you actually need.
Check your work
- You have five baseline numbers, and you know which segment they describe
- You can state the difference between hit rate and verified rate without hedging
- You have a written miss behavior for your motion
- You know your starting credit balance
Where this breaks
Teams evaluate providers on a sample of companies they already know well — usually customers and well-known logos. That sample is the easiest possible segment, so every provider scores high on it and the comparison tells you nothing. Benchmark on a random slice of your actual target list, including the accounts you have never heard of. The differences that matter only appear in the tail.
Further automation
Once the baseline exists, it is worth re-taking on a schedule rather than once. A monthly verified-rate check on a fixed sample is how you notice a segment degrading before a campaign does it for you. Lesson 08 builds that as a recurring run.
Next lesson
02 — The work email waterfall, running your baseline list through Find work email and comparing the result against the five numbers you just wrote down.
Reference for this lesson: Find work email, Verify email, Credits, Actions.