Lead enrichment should reduce explicit unknowns while preserving source and time; it cannot replace qualification judgment.
T+0: a hypothetical lead enters the CRM
A hypothetical lead arrives with the name Maya Chen, a work email at a company domain, a country selected on a form, and a note that says 'industrial packaging project.' This hypothetical lead is not a real customer or performance case. At T+0, the record contains observations, not qualification. The email may identify a mailbox but not current employment. The country may describe the person's location, the project, or a form default. The note may describe curiosity rather than a funded need. Lead enrichment begins by preserving those raw inputs and asking what must be known for the next permitted decision. It does not begin by filling every available property. I leave the raw submission untouched. I've learned that a cleaned record can make me forget how little we knew at arrival, and I don't want the next reviewer inheriting my confidence without my uncertainty.
| Input | Known | Still unknown |
|---|---|---|
| Name | Submitted string | Identity |
| Submitted address | Current employer and validity | |
| Country | Selected value | Meaning and serviceability |
| Project note | Submitted words | Need, authority and timing |
Output of this stage
A normalized but unchanged raw record, a list of identity keys, and a stated routing question. If the next decision does not need a field, the field is not requested yet. Store the output beside the evidence and the rule that produced it. The following stage may consume the accepted result, but it must not silently reinterpret an unresolved value, broaden the permitted purpose, or discard the path back to the original input.
T+1: resolve identity before adding context
Normalize the name, domain, company string, location, and known channel, then generate candidates. Separate candidate generation from match acceptance. A rich returned profile is not evidence that it belongs to Maya. Compare employer, domain, role, location, and dates; preserve alternative candidates; set a confidence rule; and route ambiguous results to review. If the email is generic or the company has several entities, pause rather than attaching an attractive profile. The output is an accepted person-company link, an unresolved state, or a documented rejection. Each is operationally useful because each tells the next stage what it may safely do. I don't accept the richest candidate by default. I line up employer, domain, role, location, and dates, then I write down why we accepted the link or why I sent it back for review.
Failure return
When evidence conflicts, return to the raw record with a review flag. Do not allow downstream scoring to convert uncertainty into confidence merely because more fields are present. The return path is part of the workflow, not an operational embarrassment. It identifies the missing evidence, preserves the last defensible state, names the reviewer or source needed next, and prevents downstream automation from treating absence of certainty as permission to proceed.
T+2: request the smallest useful field set
Suppose routing needs company identity, operating country, broad industry, business role, and Maya's current function. Request those fields first. Company size, phone, technology, hiring, ownership, and contextual changes may be useful later, but each has a cost, definition, time boundary, and privacy implication. Attach source, retrieval time, observation time where available, match confidence, and transformation to every accepted value. Keep raw, candidate, accepted, and derived values distinguishable. A completed title field should not automatically become seniority, buying authority, or persona fit. Those are separate classifications with their own rules. I've stopped ordering every available field. I ask what today's route needs, and I keep the unused fields out. That choice saves cost, but more importantly, it keeps our purpose visible.
- Accepted person-company identity
- Company field with definition and source
- Current role evidence and date
- Required contact channel with permissible-use rule
- Confidence and reviewer status
- Fields deliberately not requested
Output of this stage
A bounded enrichment bundle created for one routing purpose, not a universal profile that silently authorizes every future campaign. Store the output beside the evidence and the rule that produced it. The following stage may consume the accepted result, but it must not silently reinterpret an unresolved value, broaden the permitted purpose, or discard the path back to the original input.
T+3: send conflicts down visible branches
Imagine the provider says Maya works for Northstar Packaging Group while the submitted domain belongs to Northstar Packaging Systems GmbH. One source lists procurement; another lists operations. Do not flatten the conflict into the most complete row. Branch it. The company mismatch may be a parent-subsidiary relationship, an old employer, or a shared domain. The role mismatch may reflect a job change or different taxonomy. Low-impact formatting differences can normalize automatically. High-impact identity, employer, role, phone, and consent conflicts require evidence or review. Record the accepted value, rejected candidate, reason, reviewer, and time so the next refresh does not repeat the same argument. When two values disagree, I don't let the connector settle the argument for me. I keep both candidates, check the dates, and record who made the call. We can revisit evidence; we can't revisit a value we erased.
| Conflict | Default path | Reason |
|---|---|---|
| Formatting | Normalize | Meaning unchanged |
| Industry mapping | Rule plus review sample | Taxonomy-dependent |
| Employer | Human review | Identity impact |
| Role | Check date/source | Routing impact |
| Contact channel | Verify and apply use rule | Outreach impact |
Failure return
If the conflict cannot be resolved, preserve the unresolved state and route accordingly. Unknown is a valid operational result; invented certainty is not. The return path is part of the workflow, not an operational embarrassment. It identifies the missing evidence, preserves the last defensible state, names the reviewer or source needed next, and prevents downstream automation from treating absence of certainty as permission to proceed.
T+4: route the lead without calling it qualified
The enriched record can now support accept, reject, nurture, hold, investigate, or route decisions. It still does not prove fit, authority, need, timing, budget, or purchase intent. Write the route as a reasoned rule: the company matches the defined serviceable segment; Maya's current function is relevant enough for review; identity confidence passes the threshold; the project note remains unverified; therefore the record goes to research rather than directly to sales-qualified status. Keep evidence and score separate. A score may summarize rules, but a reviewer must be able to reconstruct the factors and reverse the route when a field, taxonomy, or business condition changes. I write the route as a sentence, not just a score. We accepted the company fit, we haven't established need, and we're sending the record to research. That sentence catches mistakes a colored badge won't.
Output of this stage
A route, a reason, an owner, a response window, and a reversal condition. If any of those are absent, enrichment has produced data without an accountable next action. Store the output beside the evidence and the rule that produced it. The following stage may consume the accepted result, but it must not silently reinterpret an unresolved value, broaden the permitted purpose, or discard the path back to the original input.
T+5: use OKKI Go after the company hypothesis is reviewable
If Maya's company is relevant but the original lead should not be treated as the only route into the account, OKKI Go can support the downstream company-prospecting step. The user states the product, buyer type, target countries, and exclusions; reviews candidate companies; corrects the route; and selectively unlocks the companies worth pursuing. Contact discovery and draft preparation follow for selected companies, with the user confirming recipient, subject, and body before sending. This does not make OKKI Go a lead-enrichment provider and does not turn Maya's form submission into purchase intent. It gives the team a reviewable way to act on a company hypothesis without hiding the human decisions. At the OKKI Go handoff, I check the company hypothesis again. I don't treat Maya's form as permission to contact anyone we can find; we review the candidates, the contact, and the draft before we move.
Failure return
When company candidates do not fit, correct the search route or stop. Do not use the existence of an enriched lead as permission to force a wider prospect list. The return path is part of the workflow, not an operational embarrassment. It identifies the missing evidence, preserves the last defensible state, names the reviewer or source needed next, and prevents downstream automation from treating absence of certainty as permission to proceed.
T+30: review corrections, not just fill rate
A month later, inspect what happened to records like Maya's. Measure match acceptance, field-level usable coverage, conflict rate, reviewer correction, route reversal, stale observations, duplicate creation, suppression success, and time to a defensible decision. Fill rate is only one input. A field can be populated and attached to the wrong entity, current but irrelevant, or valid but impermissible for the action. Keep raw input, normalized key, provider response, accepted value, reviewer correction, delivered value, and downstream outcome separable. Update the match or route rule when corrections cluster, and replay representative records before changing production behavior. At the monthly review, I start with corrections and reversals. I've found that success rows flatter the workflow, while corrected rows show me where our match rule, taxonomy, or handoff actually needs repair.
| Measure | Question |
|---|---|
| Match acceptance | Did identity evidence hold? |
| Correction rate | Which fields needed people? |
| Route reversal | Did added context change the decision? |
| Staleness | Which observations expired? |
| Suppression | Were objections and exclusions honored? |
| Decision time | Did enrichment reduce uncertainty efficiently? |
The lifecycle rule
Lead enrichment is complete when the organization can explain what changed, why the next route was allowed, and how a future correction will propagate—not when every cell is filled. Keep this distinction attached to the record and the decision it supports. A later reviewer should be able to reconstruct the source, scope, time boundary, alternative explanation, and condition that would reverse the conclusion without relying on team memory.
Replay corrected and reversed records through the lifecycle, then update match and routing rules only when the new behavior remains explainable.
Frequently asked questions
What is lead enrichment?
Lead enrichment adds or verifies company, role, contact, and contextual information around an existing lead so a team can segment, route, research, or communicate with better evidence.
What data is added during lead enrichment?
Possible fields include company identity, industry, size, location, job title, seniority, function, work email, phone, and dated company context. Add only fields with a documented operating purpose.
Does an enriched lead become a qualified lead?
No. Enrichment reduces unknowns. Qualification still requires explicit evidence of company fit, role relevance, need, timing, authority, or other team-defined criteria.
How should lead-enrichment quality be measured?
Measure match acceptance, usable field coverage, freshness, conflicts, duplicates, role corrections, false routing, reviewer time, and downstream reversals—not fill rate alone.