Client Lead Generation: What the Evidence Changes
2026-09-07 · Julian Hartwell
Client lead generation should be designed around the client's ability to accept and work a lead, not only the provider's ability to produce one. Define the client’s acceptance rule and operating capacity before selecting channels or promising lead volume.
Define a lead the client can work
Client lead generation should begin with an acceptance contract, because “more leads” is not a testable deliverable. For an industrial packaging client, the contract might require a company in two named countries, a distributor business model, relevance to food packaging, a current commercial role, a dated source, and an explicit exclusion list. The client must also define what is not promised: a matching record is not evidence of active demand, budget, or willingness to meet. General market-research guidance from the SBA and business.gov.au can inform target-market definition, but neither source validates a provider’s lead quality or a specific campaign outcome. The contract should define precedence when sources disagree. A current company page may establish the stated business model, while an older directory entry remains useful history but cannot silently override it. Person-level fields require their own rule because a correct company does not make every employee relevant. The parties should also agree how translated pages, parent-subsidiary relationships, and companies serving multiple market roles are handled. These boundary cases make the criteria usable under real delivery pressure. Without them, reviewers tend to accept familiar examples and debate difficult records inconsistently, which produces a moving target for the provider and an unreliable queue for the client. Keep 12 versus 40 as a labeled weekly-capacity assumption. If the client cannot work 40 records, delivering 40 is not acceptance.
- Eligible company type and geography.
- Required role, evidence source, and freshness rule.
- Named exclusions and duplicate-handling policy.
- Accepted, returned, and unresolved statuses with reasons.
Acceptance begins after delivery
A signed acceptance rule protects both parties. The provider can build to observable fields; the client can reject against the same rule instead of changing the definition after delivery. The acceptance schedule should include examples at the boundary. A wholesaler that also runs a consumer shop may be accepted only when the cited evidence shows the relevant wholesale unit. A company with the correct sector but no current source may be held rather than rejected. These examples reduce interpretive drift during delivery and provide a neutral basis for resolving disputes. They also prevent the provider from filling missing facts with confident assumptions.
Build the delivery contract backward
A delivery record should preserve the evidence used for every accepted field. One submitted record for Meridian Trade lists Germany, “distributor,” and a procurement contact. The client returns it because the cited page shows a consumer retailer, not a distributor. The provider corrects the business-model classification, withdraws the contact and draft that depended on it, and replaces the record only after a second reviewer verifies the source. The return reason is not hidden in email; it is attached to the record, dated, and included in the next calibration. The [OKKI Go platform](https://go.okki.ai/) may be included in a provider’s operating method for discovery or workflow. Any contractual statement should describe the exact supported step and the client-side review that follows. It should not promise that the platform independently proves company fit, contact accuracy, demand, or legal permission. Those conclusions require field-level evidence and the parties’ own review.
- Provider submits the record with field-level provenance.
- Client accepts, returns, or holds it using a contract reason.
- Provider corrects the source field and dependent data.
- Both sides preserve the original version for audit and learning.
The data contract at the handoff
This example demonstrates a worked correction, not a performance claim. One corrected delivery does not establish a general accuracy rate. The evidence supports only whether the record met the agreed fields at the time of review. It cannot predict acceptance in a different market or later period.
Know when supply is not the bottleneck
Capacity belongs in the contract as well. Assume, for planning only, that a two-person client team can meaningfully review twelve new records per week. Delivering forty may create a queue that ages before action. The provider should label twelve as an operating assumption, observe actual review capacity, and adjust the next delivery rather than presenting the number as an industry benchmark. Lead volume, review capacity, and sales follow-up capacity are separate constraints. A client may therefore accept fewer records with complete evidence over a larger file that cannot be reviewed.
- Planned delivery volume is capped by observed review capacity.
- Unreviewed records do not count as accepted work.
- Stale records return to verification before later use.
- A capacity change requires a dated contract update.
Capacity changes lead value
The appropriate unit is a reviewable record, not a row in a spreadsheet. This distinction prevents volume from masking incomplete identity, evidence, or ownership. A service-level term is most useful when it governs an observable action: review completed, return reason supplied, correction acknowledged, or stale evidence rechecked. Fixed promises about reply or meeting rates are different because external buyer behavior is not controlled by either party. If commercial targets are discussed, they should be labeled as goals with defined cohorts and dependencies, not presented as certain outputs of lead delivery.
Refuse volume-only accountability
Accountability should be divided explicitly. The provider owns source capture, classification, duplicate control, and correction of submitted fields. The client owns ICP decisions, product constraints, suppression information, response handling, and feedback on acceptance. A platform can support discovery or workflow, but its product description does not transfer those decisions to the software. OKKI Go use-case material may be reviewed as a capability reference; buyer intent and campaign results still require client evidence. The [OKKI Go use-case material](https://go.okki.ai/use-cases) can provide questions for the joint system review: where a candidate originated, which fields were proposed, and where a human confirmed the external action. The provider should demonstrate those controls using a sample from the client’s actual scope. A capability description remains vendor evidence until the client’s controlled test verifies its behavior. Escalation also needs an owner. A disputed classification should go to the client’s named commercial decision-maker, while a provenance defect returns to the provider’s research lead. A compliance question goes to the designated reviewer for the relevant market and channel. These routes prevent account managers from improvising policy inside delivery comments. The decision, rationale, and effective date should be attached to the criteria version so a later cohort is judged under the corrected rule rather than the reviewer’s memory.
- Provider: provenance, classification, delivery log, and correction.
- Client: ICP, exclusions, permissions, response disposition, and feedback.
- Shared: versioned definitions, review cadence, and escalation path.
- Neither: infer demand merely from a matching company profile.
Provider and client share the diagnosis
For direct outreach, applicable rules vary by jurisdiction and channel. ICO material is useful within its UK scope, while other markets require their own review. The contract should name the operating countries and compliance owner rather than offering a universal legality statement.
Test the joint operating system
A monthly joint review should reconstruct one accepted record, one returned record, and one unresolved record from source to disposition. The parties then inspect whether the written definition caused the result. If retailers are repeatedly returned, the business-model test is too weak. If valid records wait untouched, delivery volume or client ownership is the problem. If contacts are correct but replies show product mismatch, the ICP needs product-level refinement. Each finding should change one definition, field, or responsibility before the next delivery.
- Sample records by status, not only successful examples.
- Compare return reasons with the current acceptance language.
- Assign one corrective action, owner, and effective date.
- Recheck corrected records before using them in outreach.
A service review with consequences
Client lead generation becomes governable when acceptance, delivery, correction, and later disposition remain connected. The system should make disagreement diagnosable; it should not manufacture certainty about commercial outcomes. The review record should end with a decision that changes future work. A returned retailer can lead to a sharper distributor test; an untouched accepted record can lead to a lower delivery cap; repeated product mismatch can lead to a revised ICP. If no definition or responsibility changes, the meeting has produced commentary rather than process improvement.
Design client lead generation around the receiving team’s ability to accept and work a record. Capacity and acceptance criteria come before source expansion.
Frequently asked questions
What makes a generated lead acceptable to a client team?
Named acceptance criteria the receiving owner can apply: fit, evidence, capacity, and a next action. Provider volume is not client acceptance.
How should 12-versus-40 capacity figures be read?
As labeled planning assumptions for a receiving team’s weekly working load, not as a benchmark. If the client cannot work 40 records, 40 is not a successful delivery.
What should a client-lead contract define besides volume?
Evidence required for acceptance, the reject reason codes, the revision window, and who owns follow-up after handoff.
When should a provider stop adding sources?
When the client’s acceptance criteria or weekly capacity is already the constraint. More sources then create unworked records, not more clients served.