How to enrich a B2B contact list with work emails and direct phone numbers at scale.

The direct answer

To enrich a large B2B contact list safely, do not upload one opaque file and judge success by how many cells become non-empty. First freeze the identity, account qualification, field purpose, and eligibility rule for every row. Then process only eligible rows in bounded batches, preserve found, not_found, pending, and failed separately, and write each result back to the original row. Measure usable yield, confirmed identity accuracy, unresolved share, total credits, review time, and cost per accepted contact—not raw fill rate.

In Leadbase, direct enrichment_start batches contain 1–100 independent research items. One email or phone question per person fits up to 100 people; separate email and phone questions fit up to 50 people with both fields. A 5,000-person list therefore needs at least 50 single-field or 100 dual-field direct batches. An existing Sheet can instead run the configured research across its selected rows with sheets_enrich, while Leadbase manages admission and dispatch.

1. Define what “at scale” actually means

Scale is not the number of rows in the input file. It is the ability to finish a large workload without losing the answer to five questions: which identity was submitted, why the row was eligible, what operation ran, what came back, and what the team decided next. A workflow that fills 5,000 rows but cannot distinguish no-result from technical failure is not mature. A 100-row run with complete lineage can be safer and more useful.

Use four separate units:

Do not describe 5,000 source rows as 5,000 lookups until duplicate, stale, ineligible, and insufficient-identity rows have been classified. Do not describe 3,500 found values as 3,500 accepted contacts until the identity and intended-use review has happened. Every funnel stage needs its own denominator.

2. Separate prospecting, enrichment, verification, and outreach

These jobs are often collapsed into “get contact data,” which makes claims impossible to audit.

• Prospecting discovers net-new companies or people that may match a written market rule.
• Qualification decides whether a company and role are relevant enough to justify contact work.
• Enrichment requests a missing field for a known identity.
• Verification tests whether the returned value meets a defined technical or human acceptance rule.
• Outreach eligibility decides whether the team may use that contact in a named country, channel, and purpose.
• Outreach execution sends a message or makes a call and records the outcome.

Leadbase supports the research and enrichment working layer. Leadbase is not your legal adviser, CRM system of record, consent engine, sequencer, or dialler. Keep those boundaries visible. A found phone is not evidence of consent or current ownership. A work email with quality verified is not a promise that a message will reach the inbox, be wanted, or comply with every jurisdiction.

This Guide owns the table-scale enrichment operation. For the narrower agent and direct-phone contract, use the Claude Code and Codex phone Guide. For selecting companies before contact work, use the ICP account-list Guide.

3. Freeze a source-row contract before the first lookup

Every source row needs enough evidence to resolve the person without inviting the tool or reviewer to invent missing context. Use at least:

The underlying direct-phone action needs a canonical LinkedIn identity; email lookup supports that route or first name, last name and company domain. Public research can resolve missing identity context from the known facts you supply. Do not make up a profile, merge different people, or claim a name-only input is already a resolved identity. Preserve conflicts for review.

Reject before lookup when the domain is a directory or social domain, the profile could refer to more than one person, the employer is contradicted by current evidence, the account no longer passes the ICP, or no owner can explain the intended use. A no-result from a clean identity is useful evidence; a found result from an ambiguous identity is expensive uncertainty.

4. Design columns for state, not just values

Two columns called email and phone are not enough. Use a small state machine for each requested field.

Keep queued or running jobs visible instead of replacing them with empty results. In the ledger, pending is an editorial category for unfinished work. Never convert a failed or cancelled execution into a completed no-result. Never remove an ineligible source row merely to increase the apparent coverage rate. Preserve the source count and derive every metric from explicit states.

For large runs, add a run_id and contract_version. If the team changes identity acceptance, country policy, or lookup provider settings halfway through the queue, close the current run and begin a new version. Mixing definitions creates a number that looks precise but cannot support a decision.

5. Choose direct batches or Sheet enrichment

For a direct batch, call enrichment_start with idempotencyKey and 1–100 items. Every item has a stable id, known scalar facts in input, its own question, and a typed output. Use output: {"type":"email"} for work email and output: {"type":"phone"} for direct phone. A batch may mix these questions.

minimum direct submissions = ceiling(research items ÷ 100)

For 5,000 eligible people, one field each means 5,000 items and at least 50 submissions. Email plus phone as separate items means 10,000 items and at least 100 submissions. Use smaller batches when appropriate for the pilot or available budget. These are submission counts, not a promise that all work runs simultaneously.

For an existing Sheet, call sheets_enrich on each requested column with the eligible row IDs. For example, {"idempotencyKey":"contact-email-pilot-01","sheetId":"YOUR_SHEET_UUID","column":{"columnId":"YOUR_EMAIL_COLUMN_UUID"},"rowIds":["YOUR_ELIGIBLE_ROW_UUID"]}. A new column may instead use column: {"name":"Work email","question":"Find this person's work email.","type":"email"}. Repeat for a phone column with a distinct operation identity. Leadbase manages per-cell admission and queueing; an external worker pool is unnecessary.

Keep a stable source-row/item mapping. Read direct research with enrichment_get and the returned batchId; read Sheet progress with sheets_get_enrichment_status and values with sheets_query. See bulk research.

The planner below models the difference between requesting contact actions for every candidate and qualifying first. Its found rate is your assumption. It estimates contact-action credits only; add measured research costs and review time separately.

6. Treat email and phone as separate paid questions

Do not enrich both fields on every row merely because the input has two empty columns. Decide what action each field enables.

An email-first path can be appropriate when the approved channel is email and a work address is enough. A phone-first path can be appropriate when calling is the approved motion and a canonical LinkedIn identity is available. A sequential path can request email first, then phone only for accepted priority accounts or for contacts whose email route is unsuitable. A dual-field pilot can be useful for measuring channel coverage, but it should not silently become the default for all 5,000 people.

The underlying contact-action component currently costs one credit per found work email and five per found phone. Replaying the same operation does not create another contact-action charge; no-result and failed contact actions have no contact-result charge. Measured AI, web and identity research can still cost credits, including when the final contact array is empty. Budget and reconcile the whole research job, not only found contact actions.

Plan credit exposure with a ceiling, not a single estimate:

maximum result credits = email-eligible rows × 1 + phone-eligible rows × 5

That is a product-contract ceiling only when every lookup returns found. It excludes research, people discovery, human review, downstream systems, calling, and sending. Replace assumptions with the actual billing record after the run.

7. Use idempotency for recovery and IDs for polling

Give every new direct batch or Sheet research operation a stable idempotency key. If a submission is interrupted before you receive its identity, retry the unchanged input with the original key. Do not create a new key for an ambiguous paid submission.

Once the IDs are known:

1. Store the returned batch and job IDs or Sheet cell run identities against the source rows.
2. Read direct progress with enrichment_get({"batchId":"BATCH_ID_FROM_START"}).
3. Read Sheet progress with sheets_get_enrichment_status and saved values with sheets_query.
4. Keep running jobs separate from completed email/phone arrays and failed jobs.
5. Inspect billing status and actual credits; accounting may still be pending after the result completes.
6. Stop adding work at the agreed boundary and report unfinished jobs explicitly.

A public batch contains independent research jobs. Their terminal execution states are completed, failed and cancelled; queued and running mean work remains. Billing is separate: pending or reconciliation_pending is not settled, and credits: null means unknown rather than zero.

8. Give the agent a bounded scale instruction

Work only on the accepted accounts and supported roles in the selected Sheet.Preserve every source row and do not invent person identities or contact values.
Research the email column and phone column separately with sheets_enrich on theeligible row IDs. Let Leadbase manage cell admission and dispatch. Read statuswith sheets_get_enrichment_status and saved values with sheets_query.
If the workload starts outside a Sheet, use enrichment_start with 1–100 items.Use one stable item ID per person/field, output type email or phone, and theknown person/company/profile facts. Up to 50 people fit when both fields useseparate items. Keep each new batch's key, returned batchId and job IDs.Read progress with enrichment_get; do not resubmit to poll.
Keep execution progress, final arrays, no-result, failure, evidence, review andbilling separate. Report actual settled credits and pending accounting. Do notretry ambiguous paid submissions with a new key. Stop adding work at the agreedcredit, time or error threshold and return unfinished rows with their reasons.

Start with a representative small cohort, verify the selected rows and measured costs, then increase the queue size under the same contract. The full list can be processed without one manual action for each contact.

9. Review identity before celebrating coverage

Returned coverage is:

found ÷ submitted

It says nothing about whether the found value belongs to the intended person. Review a defined sample or every high-risk result and classify it as confirmed correct, confirmed incorrect, inconclusive, or not reviewed. Then calculate:

confirmed identity accuracy = correct ÷ (correct + incorrect)

Keep inconclusive and not-reviewed counts visible beside that rate. Excluding them from the accuracy denominator is acceptable only when readers can see how much of the found set remains unresolved. Also report usable yield:

usable yield = accepted for the intended action ÷ submitted

Usable yield is often the more commercial measure because it preserves no-results, identity mistakes, policy failures, and irrelevant fields in the denominator. The interactive scorecard below keeps those layers separate.

10. Build a cost model that includes human work

Provider credits are only one cost. Calculate:

fully loaded run cost = all settled research and contact-action credits × internal credit value + reviewer hours × loaded hourly cost + fixed tooling or setup cost

Then divide by accepted outcomes, not returned values:

cost per accepted contact = fully loaded run cost ÷ accepted contacts

Use separate cost per accepted email and cost per call-eligible phone because their review and downstream actions differ. If one person produces both fields, allocate shared identity-review time under a written rule rather than counting the saving twice.

A 5,000-row hypothetical illustrates the funnel. Suppose 3,200 people pass account and role review, creating 2,600 email items and 900 phone items. Grouped by field, that is at least 26 email batches and nine phone batches at 100 items each. If 1,820 emails and 540 phones are found, the contact-action component is 1,820 + 2,700 credits. Add actual measured research charges and reviewer time to get the whole cost. These invented inputs are not Leadbase coverage or a price quote.

11. Keep legal and channel review outside the lookup result

Contact data can be personal data even in a business setting. The European Commission says processing must have a specified purpose, be limited to what is necessary, remain accurate for that purpose, and not be retained longer than necessary. Those are controller obligations, not properties a returned quality label can satisfy. European Commission: GDPR principles

Rules also vary by jurisdiction, recipient type, and channel. The UK ICO, for example, distinguishes corporate from individual subscribers and says UK GDPR still applies when business-contact personal data is processed. Its guidance is under review after legislative changes, which is itself a reason to record the jurisdiction and review date rather than paste “GDPR compliant” into every row. ICO: business-to-business marketing

Before handoff, retain the intended purpose, legal or policy review owner, country, channel, suppression result, objection history, transparency route, retention rule, and permitted next action. This Guide is operational guidance, not legal advice.

12. Why Leadbase is a strong fit for this job

Leadbase is a strong fit when the goal is not merely to enrich a file, but to move from an exact ICP to a qualified market and then make its relevant decision-makers reachable at scale.

Leadbase brings the complete path from your market definition to reachable people into one workspace. Export the reviewed results for your existing CRM, dialling or sending workflow, with the account context your team needs for the next conversation. Enrich your first contact sample.

13. Use the downloadable run ledger

Download the large-list contact-enrichment ledger. It includes source identity, eligibility, email and phone execution state, review decisions, policy gate, credits, and batch lineage. The sample rows are fictional and illustrate found, no-result, pending, failed, held, and accepted outcomes. Replace them with your data and retain the original denominator.

Before the run, freeze:

1. source snapshot and row count;
2. duplicate and eligibility rules;
3. email and phone identity contracts;
4. per-call payload and workspace ceiling;
5. idempotency and polling procedure;
6. credit and time ceilings;
7. review sample and acceptance definitions;
8. jurisdiction, channel, and suppression ownership;
9. run cutoff and rollback or export process; and
10. metrics that will decide scale, revise, or stop.

14. Publish the result without marketing arithmetic

Report source, eligible, submitted, found, not found, pending, failed, confirmed correct, confirmed incorrect, inconclusive, not reviewed, accepted, and policy-blocked counts. Include the exact dates, segments, field definitions, payload, workspace rules, and review method. Do not present a blended email-plus-phone fill rate. Do not compare your observed segment with a vendor's global marketing number.

Leadbase does not claim to have the largest database, highest universal coverage, lowest universal cost, or exclusive access to email, phone, MCP, or bulk workflows. It claims a narrower and testable advantage: a large contact workload can remain a reviewable table while bounded capabilities perform the paid lookups and uncertainty stays visible.

The product workflow was checked on 20 October 2026. Recheck current MCP documentation, research schemas, credit policy and workspace access before a material run. Privacy guidance and target-country rules require their own current review.

15. Final checklist

• Every source row has a stable ID and preserved outcome.
• Account and role qualification happen before contact lookup.
• Email and phone have separate purposes, eligibility, and cost ceilings.
• Each direct batch contains 1–100 independent research items; two fields may use two items per person.
• Every new ordered batch receives a fresh idempotency key.
• Progress is read by batch or cell run identity; interrupted submissions preserve their original key and unchanged input.
• Found, not found, pending, and failed remain separate.
• Confirmed identity accuracy and usable yield use explicit denominators.
• Human review time is included in fully loaded cost.
• Country, channel, suppression, transparency, and retention have owners.
• The downloadable ledger matches the executed workflow.
• Scale proceeds only after a bounded pilot demonstrates the contract works.