How to automate lead enrichment without filling the CRM with guesses
Enrichment data is confident and frequently wrong. Which fields are safe to trust, what to do with a low-confidence match, and why your own data beats a vendor's.
On this page
- What we'll cover
- What enrichment is actually for
- Which fields to trust
- Matching, where the errors come from
- Building it with CodeWords
- Seven automations worth building
- Your own data beats a vendor's
- Recording where a value came from
- Enriching without asking the visitor for more
- Making it survive
- Limits worth knowing about
- What to build first
- Frequently asked questions
- Related reading
Lead enrichment fills in what a form did not ask for — company size, industry, role, location — so a salesperson opens a record that means something rather than an email address and a first name.
The part that gets skipped is that enrichment data arrives with the same confidence whether it is right or a guess. A vendor returning "250–500 employees" for a company that has forty is indistinguishable, in the record, from one that got it right. Deciding what to do about that is most of the design.
What we'll cover
- What enrichment is actually for
- Which fields to trust
- Matching, where the errors come from
- Building it with CodeWords
- Seven automations worth building
- Your own data beats a vendor's
- Recording where a value came from
- Enriching without asking the visitor for more
- Making it survive
- Limits worth knowing about
- What to build first
- Frequently asked questions
What enrichment is actually for
Being specific about the purpose determines which fields matter.
Routing. Sending a lead to the right salesperson by territory, segment, or size — which needs company size and location and nothing else.
Qualification. Deciding whether to work a lead at all, which needs whatever your qualification criteria actually use.
Personalisation. Giving the salesperson something to open a conversation with, which is better served by recent behaviour than by firmographics.
Reporting. Segmenting pipeline by industry or size, which needs consistency more than accuracy — a slightly wrong industry applied uniformly still segments.
Not "more complete records". Filling every field because a vendor offers it produces a record nobody reads and a bill that scales with volume.
Which fields to trust
Reliability varies enormously by field type, and treating them alike is the mistake.
Domain and company identity are usually reliable, since the match is on something unambiguous.
Company size and revenue are estimates, often banded, and frequently stale — a company that grew or shrank in the last year is commonly wrong.
Industry classification is approximate and differs between vendors, which matters when you switch and your segmentation shifts.
Job titles are what somebody wrote on a profile, which is not the same as their role or their authority to buy.
Technology detected on a website is genuinely useful and detects what is visible, missing anything server-side.
Personal contact details deserve particular care, both because accuracy is poor and because the obligations around them are different — which is covered below.
Matching, where the errors come from
Almost every wrong enrichment is a wrong match rather than wrong data.
Match on the email domain where you can, which is the most reliable signal available.
Free email addresses cannot be matched to a company by definition, and a vendor that returns a company for one has guessed.
Company names are ambiguous. Several businesses share a name, and matching on it produces confident nonsense.
Ask for a confidence signal and use it. A match below your threshold should be left empty rather than filled.
Empty beats wrong. A blank field prompts somebody to find out; a wrong one is acted upon. This is the single most important principle here.
Report the match rate, since a sudden drop means the vendor changed something and your records are quietly getting worse.
Building it with CodeWords
CodeWords connects to more than 3,000 integrations, so enrichment can combine a vendor, your own product data, and your CRM in one automation.
- Open CodeWords and start a new automation.
- Describe what should happen in plain language to Cody, the automation builder: which records, which fields, and what to do when the match is uncertain.
- Authorize the connections — the enrichment source, the CRM, and your own systems.
- Describe the exceptions: a free email domain, a low-confidence match, a field that already has a value somebody set by hand.
- Run it against a small set of records you know well and check the results before enriching anything else.
You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.
Seven automations worth building
Enrich on creation, immediately, so the record is useful the first time anybody opens it rather than after a nightly batch.
Routing from enriched fields, which is the concrete payoff — territory, segment, or size deciding who gets the lead.
Fill gaps only. Never overwrite a value a person entered, since they had a reason and the vendor did not.
Re-enrich on a slow cycle for records that matter, because company size and technology change and a two-year-old value is a guess.
Flag the unmatchable, so somebody can decide whether a free-email lead is worth pursuing rather than it sitting with empty fields.
Enrich from your own product data — usage, plan, support history — which is more accurate and more useful than anything purchased.
Report the match rate and the fill rate weekly, which is how you notice the vendor degrading before your segmentation does.
Your own data beats a vendor's
Consistently overlooked, and it is free.
Product usage tells you more than firmographics. Whether somebody has actually used the thing is a stronger signal than how many employees their company has.
Support history says whether this account is happy, which changes how a salesperson should open.
Billing status is definitive where a vendor's revenue estimate is a band.
Previous conversations with anybody at the same domain are usually the most useful context available and are routinely missed because nobody joins on domain.
Your own data is accurate by construction, current, and costs nothing per record — which is a strong argument for building that join before buying a second enrichment vendor.
Recording where a value came from
The practice that makes enrichment auditable and is almost never done.
Record the source per field — entered by a person, supplied by a vendor, derived from your own systems.
Record when. A value from eighteen months ago should be treated differently from one from last week.
Record the confidence where the source provides one.
It changes what you can do. Knowing which fields are vendor guesses lets you re-enrich only those, overwrite safely, and explain a segmentation to somebody who questions it.
It also survives a vendor change, since you can identify and refresh everything that came from the old one rather than living with a mixture.
Enriching without asking the visitor for more
The tension behind all of this: every field you add to a form loses submissions, and every field you do not ask for has to come from somewhere.
Ask for the minimum. Email and name convert; a ten-field form does not, and the fields people fill in under protest are frequently wrong anyway.
Derive what you can from what they gave you. The email domain yields the company, and the company yields most of the firmographics.
Ask progressively. A second interaction is a better moment to ask for role or team size than the first, and by then the person has a reason to answer.
Let behaviour do the qualifying. Which pages somebody read and what they downloaded says more about intent than a self-reported job title.
Do not ask for what you will overwrite. A form field that enrichment will replace anyway is a field that cost you conversions for nothing.
Test it. The trade between form length and lead quality is measurable, and most teams assume rather than measure.
Making it survive
Never overwrite human-entered values, which requires knowing which those are — see above.
Handle the vendor being unavailable by leaving the record unenriched and retrying, rather than writing partial data.
Deduplicate before enriching, since enriching four copies of the same company costs four times as much and produces four records to reconcile.
Cap the spend. Enrichment is usually priced per lookup, and an automation enriching every record on every change is an expensive mistake.
Report the outcome. Records enriched, matched, unmatched, and skipped because a person had already filled the field.
Limits worth knowing about
Coverage varies by region and company size. Small businesses and non-English-speaking markets are consistently worse covered, and a vendor's headline accuracy figure will not say so.
Pricing is usually per lookup, so cost scales with volume and with re-enrichment frequency.
Data ages. Company size, technology, and roles all change, and a record enriched once is a snapshot.
Vendors disagree, sometimes substantially, on industry and size — which is worth knowing before treating either as fact.
Personal data carries obligations that differ from company data, including in several jurisdictions a requirement to tell people what you hold and where it came from.
What to build first
Enrichment at the point of creation, filling only empty fields, with a confidence threshold below which the field stays blank. It makes the record useful immediately, it cannot damage anything a person entered, and the threshold is what keeps the CRM free of confident guesses.
Two habits make the difference. Leave the field empty rather than filling it with a low-confidence match, since an empty field prompts somebody to find out and a wrong one gets acted on. And record the source and date on every enriched field, because that single addition makes it possible to refresh, audit, or unwind the enrichment later.
Frequently asked questions
Which enrichment fields are reliable?
Domain and company identity, usually. Size and revenue are banded estimates that go stale, industry classification is approximate and differs between vendors, and job titles are what somebody wrote on a profile rather than their actual authority.
What should happen to a low-confidence match?
Leave the field empty. An empty field prompts somebody to find out; a wrong one is acted on and propagates into routing and reporting. This is the single most important rule in enrichment.
Should enrichment overwrite existing values?
Never a value a person entered — they had a reason and the vendor did not. Overwriting a previous vendor value is fine, which is why recording the source of each field matters.
Why do the numbers differ between vendors?
Because size and industry are estimates derived differently. It is worth knowing before treating either as fact, and it is why switching vendors quietly shifts your segmentation.
What is the most underused source?
Your own data. Product usage, support history, billing status, and previous conversations with anyone at the same domain are more accurate and more useful than purchased firmographics, and cost nothing per record.
How do I control the cost?
Deduplicate before enriching, enrich only empty fields, re-enrich on a slow cycle rather than on every change, and cap the spend. Enrichment is priced per lookup, so an eager automation is an expensive one.
Are there rules about enriching personal data?
In several jurisdictions, yes — including telling people what you hold and where it came from. Company data and personal data carry different obligations, and it is worth raising with whoever advises you before enriching the second.
How many fields should the form ask for?
As few as convert well — usually email and name. Most firmographics can be derived from the email domain, and a field that enrichment will replace anyway cost you submissions for nothing.
What predicts intent better than firmographics?
Behaviour. Which pages somebody read, what they downloaded, whether they came back. A self-reported job title is what somebody typed; the behaviour is what they actually did.