The short answer: lead enrichment adds available information to a known person or lead record. This guide explains the fields, inputs and evaluation decisions. For production rollout, CRM write controls and acceptance gates, use the separate enterprise lead-enrichment activation guide.
What is lead enrichment?
A lead captured with a name and company may lack a work email, role or company context. Enrichment attempts to fill those gaps using supported identifiers. A lookup can return some fields and leave others unresolved. It does not turn an incomplete record into a guaranteed current, reachable or qualified buyer.
Separate three jobs: appending a missing value, checking evidence for an existing value, and refreshing a value whose underlying facts may have changed. An API that retrieves fields does not necessarily perform all three. Ask what each result actually establishes.
A field dictionary for an enrichment request
| Field group | Question it answers | Evidence still needed |
|---|---|---|
| Person identity | Which person is this? | Namesake resolution and supporting identifiers |
| Employment | Which employer and role are associated? | Source date and current employment |
| Work email | Which business address is available? | Mailbox assessment and applicable outreach permissions |
| Business phone | Which number is associated? | Ownership and line type where required |
| Company context | What is known about the account? | Legal entity, source date, units and estimated versus reported values |
Start with the decision you want to make. Routing by company size may require a headcount band; contacting a known person may require a work email. Requesting every available field increases the amount of data you must interpret and maintain without necessarily improving that decision.
Choose inputs before choosing a provider
A name alone can be ambiguous. A name with company context, a professional profile URL or a known work email can identify different lookup routes, depending on the provider. Confirm the supported input schema rather than trying every combination and counting each attempt as a new lead.
Keep the original record ID with the request. Normalize obvious formatting differences, but preserve the supplied value alongside the normalized value. When the person or employer is ambiguous, send the record to review instead of forcing a match.
A worked record example
Consider a fictional CRM lead with an internal ID, a person name and a confirmed company domain. Your task is to add a work email for review and a company-size band for routing. The provider returns an email, no phone, and a size band.
- Keep the CRM ID as the join key; do not create another lead just because the returned name has a different spelling.
- Store the returned email as a candidate until it meets your identity and mailbox checks.
- Preserve the phone as missing. An empty result must not erase an existing first-party number.
- Record the company-size evidence and observation date where supplied. If the source returns an estimate, keep it labelled as an estimate.
- Apply routing only after the required fields meet the routing policy. Contact permission and sending remain separate decisions.
Single-source and waterfall enrichment
A single-source lookup queries one provider. A waterfall uses additional permitted routes or sources when the required field remains unresolved. The benefit to measure is the additional accepted coverage after earlier sources, not the number of providers in a diagram.
Resolve email and phone separately. Finding an email does not settle a missing phone, and returning a phone does not prove its ownership. Continue only while the expected value of another attempt justifies its cost and latency. See the waterfall design guide for source-ordering and failure handling.
Measure returned and accepted results separately
Freeze a representative sample, requested fields and acceptance rules before comparing suppliers. Include unresolved records and errors in the attempted-input denominator. Report identity acceptance, email return, phone return and accepted results by country and customer segment.
Illustrative example: 1,000 unique submitted leads produce 700 email values, of which 560 satisfy your defined acceptance rules. Email return is 70%; accepted-email coverage is 56%; acceptance among returned emails is 80%. These are different measures. None is a delivery or meeting rate, and these hypothetical counts are not TargetWise performance.
If the evaluation costs $280 including the allocated subscription and usage, the cost is $0.50 per accepted email. Include additional review and integration costs when comparing total ownership cost. The match-rate guide explains how to design the denominator.
Where enrichment fits in your stack
An API supplies structured requests and responses; your integration owns field mapping and writes. An MCP client can call permitted tools from an assistant workflow; it still needs bounded scope, budget and review. A dashboard supports manual lookups. Availability of one mode does not establish a native bulk uploader or a ready-made CRM sync.
TargetWise offers REST, MCP and a workspace dashboard. Its contact routes retrieve available work emails and business phones for supported inputs. Unclassified phones must remain unclassified, and returned addresses are not deliverability guarantees. Inspect the operation schemas and current pay-as-you-go pricing before building.
Decide when to refresh
Use evidence of change and the consequences of stale data to set refresh rules. A first-party job update, failed contact attempt or changed account domain can trigger review. Retrieval time is not automatically the date the source last verified a field. Keep those timestamps separate when both exist.
Review high-impact fields before acting on them and measure changes within your own cohorts. This guide does not establish a universal decay rate or a weekly refresh rule for every lead.
Frequently asked questions
How does lead enrichment differ from company enrichment?
Lead enrichment concerns a person record. Company enrichment concerns an organisation or legal entity. A workflow may use both, but a company record does not identify the right individual contact.
Is a match a verified contact?
Not by itself. A match can mean that a provider found a record or returned a requested field. Identity, current employment, mailbox status and phone ownership require their own evidence.
What happens when no data is found?
Preserve missing values and distinguish no-match from a failed request. Retry only failures that warrant it, and route unresolved records according to your workflow.
What should I implement next?
Define your accepted fields and destination rules, then follow the enterprise activation guide for staging, safe writes, retries and release checks.