Finding a work email for every lead, one provider after another
A scheduled Make scenario picks up decision-maker leads in the CRM that have a company website but no email, asks one email-finder service and then a second, and writes back either the address or a dated stamp saying there is none. Each lead is paid for once, and one provider failing never stops the batch.
Where this applies
Any sales team that buys or builds lead lists with names and company websites but no email addresses, and keeps them in a CRM.
- email finders, asked in turn
- 2
- runs, 7–21 Oct, no errors
- 845
- timeout on the second provider
- 40 s
The problem
Lead lists arrive with names, titles and company websites, but often without an email address, and an outbound team can't write to a lead it can't reach. Finding the address by hand takes minutes a lead. Email-finder services do it in a second, but each finds a different share, and none finds them all.
Pointing one service at the whole list leaves a gap. Pointing two at it without care pays twice for the same lead and keeps re-asking about leads that were never going to be found. And a lead whose only website is a social-media page has no company domain to search at all.
What we built
Only leads worth asking about
Each run starts with a query in the CRM's own query language for decision-maker leads that have no email and a real company website. A router checks the website first: a lead whose only site is a social-media profile is stamped as not found, with the date, and never reaches a paid lookup.
Two providers, in order
The first email finder is asked with the person's name and the company domain. If it returns an address, the scenario writes it to the lead and moves on. If it finds nothing, or errors, a Resume handler hands back an empty answer so the lead falls through to the second provider, called over HTTP with a forty-second timeout.
Dated stamps as idempotency
Every outcome is written back with a date: the address, a not-found stamp, or a bad-data mark when the CRM rejects the write. The pick-up query leaves stamped leads alone, so a lead is looked up once, and the stamps double as a record of what was tried and when.
A provider outage is not a verdict
A failed call to the second provider is ignored rather than stamped, so that lead is simply picked up again on the next run. It is the one place the scenario deliberately retries: a provider being down is not evidence that the email doesn't exist.
Fail-soft per lead
Each write has its own error route ending in a Resume, so a lead with a bad field moves the run on to the next lead instead of stopping it. The scenario polls every few minutes, which works new leads through steadily rather than in one large pass.
The outcome
In the History read for this page, the scenario ran 845 times between 7 and 21 October 2026, every run successful.
Newly imported leads are picked up on the next poll, and leads that can't be found are marked rather than asked about again.
Where it stops
The scenario finds addresses; it does not prove they are deliverable, and checking them is a separate step not described here. A lead is looked up once: if a provider would find the address a month later, nothing asks again unless the stamp is cleared. Leads without a usable company website are skipped by design, and the two providers and their order are fixed in the scenario rather than chosen per lead.
Built with
- Make.com
- Salesforce
- Findymail
- Lead Magic
- HTTP API
Patterns used
- Provider waterfall
- Dated stamps as idempotency
- Resume to fall through
- Skip before you pay
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Have something shaped like this?
If any part of the above resembles a problem you are living with, a short call is the fastest way to find out whether it is the same problem underneath.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no