Enrich contacts with email and phone
Waterfall data enrichment for a contact list: one batch pass for email and phone, a second provider for the emails still missing, and every real gap flagged.
- Starts
- List created
- Steps
- 4
- Checks and gates
- 0
- A person decides
- Never, runs alone
Trigger · Event
List created
A newly assembled batch opens the run, so enrichment starts without anyone submitting it.
Claude runs the rest autonomously
- 1
AI gathers every identifiable contact.
The batch holds every contact with at least one way to identify them — an email, a professional profile, or a name and company.
- 2
AI enriches the whole batch at once.
DropcontactDropcontact
The whole list goes out in one request and results are collected as soon as they are ready, with no fixed wait assumed.
- 3
AI backfills missing emails.
KasprKaspr
Anyone still without a usable email gets a second, email-only pass through a profile-based fallback.
- 4
AI returns one table, flags every gap.
One clean table comes back with every real gap flagged instead of dropped, and nothing written to the CRM unless asked for separately.
Enriching a contact list by hand means opening each profile one at a time, copying what's findable, and giving up on the ones a single tool comes up empty for. On any real list, that group is large enough to matter.
One provider resolves most of a batch in one asynchronous call. The rest is a second, cheaper pass through a different provider for exactly the rows that still need it, and an honest table at the end that shows what worked, what needed the fallback, and what is still missing. It is a waterfall kept to two providers, with the second one reserved for missing emails.
What you get
A clean table, with every contact enriched where the data exists and every real gap flagged rather than dropped.
What a contact needs before enrichment
Each contact needs one identifying combination: an email, a LinkedIn URL or slug, or a first name, last name and company. Every row carries your own reference ID, because a batch call does not promise to return rows in the order they were sent, and the ID is how results map back cleanly. Contacts that may need the fallback keep their LinkedIn identifier from the start, since the fallback tool requires it. An under-specified contact never fails the batch: the enrichment tool processes what it can and reports an error or warning on that one row.
Enriching email and phone in one batch
The whole list goes to Dropcontact in one call, split into chunks only where the tool's size limits require it. The call returns a request ID right away and the enrichment runs asynchronously, so the agent polls until the result is ready instead of assuming a fixed wait. Batching the submission is what keeps this fast and cheap: one round trip for the whole list, up to the tool's own limit, instead of a request per contact.
Email quality labels are read literally. A personal, verified address at the company's own domain is the best outcome, and a generic mailbox is usable but weaker. Anything marked invalid counts as no email at all, never as a low-confidence one.
A fallback for the emails still missing
Every contact still without a usable email, and holding a LinkedIn identifier, goes to Kaspr for email only. Phone is a separate concern and not worth extra credits in this pass. A found address is used and marked with the fallback as its source, so the final table shows where each field came from.
Routing only the real gaps to a second provider, instead of running everything through both, is what keeps the fallback affordable. Most contacts resolve on the first pass, and spending a second provider's credits only on the ones that didn't is what lets the step scale.
One table, every gap flagged
The run returns one table: name, best email with its source, phone or mobile where found, and any company data the enrichment returned. Every contact neither provider could resolve is flagged and kept. A silently shortened list looks clean and hides exactly the contacts a person most needs to look at by hand. Nothing is written to a CRM; pushing the results somewhere is a separate, explicit step.
The prompt
The real prompt behind the steps above, detailed enough that an agent with the same tools can run it as written. The Run buttons copy the full version, which also carries the steps for connecting those tools.
# Enrich a contact list with email and phone
You have access to two enrichment tools: a primary one and a
LinkedIn-based fallback. Run this against **[a list of 1–250 contacts,
each with at least an email, a LinkedIn identifier, or a name and
company]**.
## 1. Gather every identifiable contact
Each contact needs at least one identifying combination: an email, a
LinkedIn URL or slug, or a first name + last name + company. Attach a
reference ID to every contact (your own row id) so results can be
mapped back cleanly — a batch call doesn't guarantee it returns rows in
the order you sent them. If a contact might need the LinkedIn fallback
later, keep its LinkedIn identifier on hand from this step; the
fallback tool requires it.
An under-specified contact doesn't fail the whole batch — the
enrichment tool processes what it can and reports an error or warning
for that one row.
## 2. Enrich the whole batch at once
Submit the whole batch in one call, not one request per contact — batch
size and per-item size limits apply, so split into chunks if you're
over them. The call returns immediately with a request id; the
enrichment runs asynchronously. Poll for the result starting around 30
seconds after submission, then every 20–30 seconds until it's done.
When results come back, treat email quality labels literally: a
personal, verified email at the company's own domain is the best
outcome; a generic mailbox is usable but weaker; anything marked
invalid counts as no email at all, not a low-confidence one.
## 3. Backfill missing emails through the fallback
For every contact still without a usable email, and that has a LinkedIn
identifier: call the fallback tool for email only — don't spend extra
credits pulling phone here, that's a separate concern. If it finds an
email, use it and mark its source as the fallback provider so the final
table shows where each field came from. If it finds nothing, or the
contact has no LinkedIn identifier to fall back on, leave it blank and
flag it in the final step — never drop the row.
## 4. Return one table, flag every gap
Return one clean table: name, best-qualified email with its source,
phone/mobile if found, and any relevant company data the enrichment
returned. Flag every contact where neither provider found a usable
email — don't drop them silently, since a flagged gap tells a human
exactly who still needs manual work.
This is a standalone enrichment step — it doesn't write anything back
to a CRM. If you want the results pushed somewhere, do that as an
explicit next step, not automatically.
## Output
Report: total contacts submitted, how many resolved on the first
provider, how many needed the fallback and how many of those resolved,
and the final list of contacts still missing an email.
Why run it with Tulina
A prompt helps one person. A process moves a team.
Pasted into a chat, the prompt above works once, for whoever pasted it. In Tulina, "Enrich contacts with email and phone" becomes a process the team shares, that keeps its history, runs on its own, and stays inside the same security perimeter as the tools it calls.
The whole team works on the same one
PersonalTeamOrganisation
A process lives where it belongs: yours, your team's or the whole organisation's. Whoever runs it can improve it, and everyone starts from the best version instead of explaining the job again.
Every edit is a version
v1v2v3
Each change is a new version with the previous one kept, so a bad edit is undone by restoring an earlier one. Every run records the version it followed, and what a run teaches goes back into the process.
It runs without you
schedulewebhookon demand
A hosted agent runs the process on Tulina's own infrastructure, on a schedule or when an event arrives, and keeps going when you close the chat. Nothing to host. Every run is tracked to its outcome.
Inside the same security perimeter
vaultrolesrun log
Credentials stay in the vault, never in the prompt. Roles decide who may run what, every call is logged, and a step a person has to approve waits for that person.
Questions about contact enrichment
Related processes
Processes that share tools with this one. The shared tools are lit.
