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, a Sheet can contain thousands of people while the low-level email or phone capability accepts at most 50 identities per call. That 50-person payload is a transport boundary, not a list limit. A 5,000-person queue can be processed through at least 100 ordered calls of 50, with smaller calls where workspace policy requires them. The value is not a magic bulk button. It is that qualification, lookup execution, uncertainty, and the commercial decision remain inspectable in one working table.

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:

Phone lookup requires a canonical LinkedIn identity under the current Leadbase contract. Work-email lookup can use that identity or a strict person-at-company identity containing first name, last name, and company domain. Supplying both routes does not permit the model to merge different people. Define one canonical identity for the row and hold 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.

Never overwrite status=pending with an empty cell. Never convert failed into not_found. 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. Calculate batching before execution

The minimum call count is transparent:

minimum calls = ceiling(eligible rows ÷ confirmed per-call payload)

For 5,000 eligible people and a 50-person payload, the minimum is 100 calls. If workspace policy allows only 20 people per call, it is 250. Retries can add calls; exact polling of a pending call is not a new logical batch, but it is another transport request. Deduplication and eligibility reduce the row count before batching.

Use a deterministic sort such as row_id, then assign batch_sequence = ceiling(queue_position ÷ payload). Freeze the precise input snapshot for that sequence. If the process stops after batch 37, it should resume at the first row without a terminal result—not rebuild every batch with new identities. A stable sequence also lets finance reconcile credits and lets reviewers reproduce a disputed result.

The planner below estimates the workload when every candidate is submitted versus qualifying accounts and roles first. Its found rate is your assumption, not a Leadbase benchmark. Enter 5,000 candidates to see why qualification can change both review volume and credit exposure even though the per-call transport boundary remains the same.

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.

At the contract date, a found work email consumes one credit and a found phone consumes five. Exact replay, not_found, pending, and failed consume none according to the current capability descriptions. This means cost depends on found results rather than submissions alone, but you must still budget review time for every returned state. A no-result may be non-billable and still require identity repair or a commercial fallback.

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 to make retries safe

Every new batch needs a fresh UUID or ULID. Reuse that key only when polling the exact same ordered input after a pending response. Never reuse it for a new group of people. Never create a new key merely because a pending result is inconvenient; that can create a second paid operation instead of resuming the first.

The safe loop is:

1. Create the frozen ordered payload and a new idempotency key.
2. Submit once and store the complete response against the original rows.
3. Mark terminal found, not_found, and failed results immediately.
4. For pending items, wait at least the returned retryAfterMs.
5. Poll with identical input and key, then update only the corresponding row states.
6. Stop at a defined cutoff and report remaining pending separately.

An agent is good at this repetitive bookkeeping only when the contract is explicit. “Enrich this CSV” is not an adequate instruction. It omits eligibility, field order, batch size, cost ceiling, pending behaviour, stop conditions, and the writeback schema.

8. Give the agent a bounded scale instruction

Use a prompt such as:

Work only in Sheet <sheet_id> and preserve every source row.
Select rows where account_state=accepted, role_state=supported,contact_lookup_eligible=yes, and the requested result has no terminal state.Order by stable row_id. Do not infer missing identities or contact values.
For work email, use either the canonical LinkedIn identity or the reviewedfirst_name + last_name + company_domain identity. For phone, require thecanonical LinkedIn identity. Hold ambiguous or stale rows for review.
Process at most the lower of 50 people and the current workspace limit percapability call. Create one fresh UUID/ULID for each new ordered batch. Reusethe identical input and key only to poll pending results.
Write found, not_found, pending, and failed to every original row with requestID, batch sequence, quality, returned value, and timestamp. Never turn failureinto no-result, delete a source row, or call a found value verified by us.
Stop before the next new batch if the configured credit ceiling, run cutoff,or error threshold would be exceeded. Return counts by every state and list allheld rows and reasons.

Run it first on redacted or non-sensitive test rows and ask the agent to show the planned selection and batch count before the first paid call. At scale, approval should be about the queue and cost boundary, not clicking through 100 identical payloads without context.

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 = lookup 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. Assume 5,000 source people, 3,200 eligible after account and role review, 2,600 email requests, and 900 phone requests. The transport creates at least 52 email calls and 18 phone calls at a payload of 50. If 1,820 emails and 540 phones return found, the current contract arithmetic is 1,820 email credits plus 2,700 phone credits. Those are illustrative inputs, not Leadbase coverage. The team still needs to review identity, acceptance, and permitted use before it knows the usable output.

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.

The product is not the best fit when your primary requirement is native bidirectional CRM writeback, an outbound sequencer, a dialler, consent management, proprietary intent, or a fully managed enterprise data-governance programme. Keep the CRM as system of record and export only reviewed results under your governance. Leadbase's advantage here is the integrated path from your market definition to reachable people; the inspectable table is the control surface that makes that path governable.

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-contract details in this Guide were checked on 9 August 2026. Recheck current MCP documentation, capability descriptions, credit policy, workspace enablement, privacy guidance, and target-country rules before a material run.

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.
• Fifty people is documented as a per-call payload, not a list limit.
• Every new ordered batch receives a fresh idempotency key.
• Pending is polled only with identical input and key.
• 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.