Lead Sourcing as a Weekly System: From ICP Rules to Verified, Usable Records

Lead sourcing is often managed like a purchase: buy a database, export a list, hand it to sales. That model hides the real work. A usable prospect record is the output of a small evidence system—identity, fit, role, contact route, freshness, rights/constraints and a reason the seller can understand. The system needs a weekly cadence because sources age, people change jobs, campaign capacity changes and legal/platform requirements differ by channel and geography.

This playbook is operational guidance, not legal advice. Email, privacy and direct-marketing rules vary by jurisdiction, subscriber type and data role. Platform policies can impose additional limits. Teams should involve qualified privacy/legal owners where appropriate rather than trying to encode one global legal conclusion into every record.

Monday: freeze the ICP version

Write the current acceptance rule before researchers start. Include required company traits, disqualifiers, relevant roles, geography, trigger conditions and what counts as sufficient evidence. Give the version a date. If sales changes the ICP midweek, do not silently reinterpret old work; record the change and decide which queued records need re-review.

Define the record evidence contract

For every important field, state whether it must be sourced, inferred or optional. A practical record may carry company identity, website/domain, location, segment fit evidence, current role, contact route, source URL(s), last-checked date, confidence/uncertainty and suppression status. The aim is not maximal enrichment. It is enough evidence for a seller or QA reviewer to reconstruct why the account exists in the queue.

Tuesday: produce in research lanes

Separate discovery from verification. One lane can find candidate companies broadly; another verifies fit and identity; a third checks relevant contacts and routes. This prevents expensive verification work on obvious nonfits. For new segments, keep more manual review because rejection reasons are still being learned. As those reasons stabilize, automate the repeatable parts.

Wednesday: run freshness and conflict checks

Sample recently created records and compare critical fields across sources. When sources disagree, preserve the conflict rather than inventing false precision. Recheck high-value fields such as employment status or company identity closer to activation. Track age at first action; a perfectly verified record that waits three months may no longer be perfectly verified.

Thursday: apply channel and jurisdiction gates

Before activation, identify the intended channel and geography. U.S. commercial email has CAN-SPAM requirements; Gmail has sender-authentication and other platform requirements; UK B2B electronic marketing treatment depends partly on subscriber type while UK GDPR can still apply to identifiable people; California data-broker obligations continue to evolve; LinkedIn restricts unauthorized scraping/automation. These are examples of why the record should carry context instead of a universal “legal=yes” flag.

Friday: sample against sales acceptance

Ask sales to accept or reject a sample with reason codes. Measure not only meeting creation but whether records are usable: correct account, relevant role, credible reason, usable route, sufficient evidence, no known suppression conflict. Feed rejection reasons back into the next ICP version. Sourcing quality is an iterative specification, not a one-time vendor score.

Match production rate to sales capacity

A sourcing team can create waste by being too productive. Compare weekly verified output with seller consumption. If the queue is aging, slow new acquisition and refresh priority records instead. Buying more data while sales cannot act on the existing queue turns freshness into inventory spoilage.

A suppression layer that is boring on purpose

Keep opt-out/suppression data separate from campaign lists and apply it consistently. Do not allow a new vendor import to “resurrect” records that should remain suppressed under the organization’s applicable obligations and policies. Preserve the reason and date so the system can explain why a record was excluded.

Quality review by reconstruction

Each week, pick a handful of delivered records and reconstruct them end to end. Can the reviewer see how the company was found, why it matched, how the role was verified, when the route was checked, what is inferred, and what changed after delivery? If one record cannot be explained, ten thousand records cannot be safely trusted just because a vendor reports a high accuracy percentage.

The output definition

A finished record is not “name + email.” It is an account that fits a current hypothesis, carries enough evidence to be reviewed, has a context-appropriate activation route, and can be removed or refreshed when facts change. That definition keeps sourcing attached to real sales work instead of becoming a volume contest.

Operator review notes before the next cycle

Audit the sourcing system by following one record that was accepted, one that sales rejected and one that was suppressed.

For the accepted record, reconstruct the ICP version, source evidence, role verification and last-check date. If any key field cannot be traced, acceptance may have depended on luck rather than process.

For the rejected record, classify the reason precisely: wrong company, wrong role, stale employment, weak trigger, unusable contact route, duplicate, or commercial mismatch. “Bad lead” is too vague to improve the next batch.

For the suppressed record, prove that a new import cannot silently reactivate it. Test the actual merge path rather than trusting a policy document.

Next, compare queue age with research throughput. If researchers are producing faster than sellers can act, the right move may be to refresh fewer priority accounts, not celebrate a larger database.

Close the review by changing one ICP rule only if the rejection evidence is strong enough to justify it. Continuous improvement is not continuous rule churn.

Final evidence-control appendix

A sourcing record should preserve lineage for the fields that drive action: company identity, fit evidence, role, contact route, source URL, checked date and any inference label. Derived fields should remain distinguishable from directly observed facts.

When two sources disagree, keep the disagreement long enough to resolve it; do not overwrite the older value merely because the newer source looks cleaner. Conflict itself is evidence about uncertainty.

Suppression evidence belongs outside campaign exports and should survive vendor replacement. The audit question is simple: can a new data file bypass an old “do not activate” decision? If yes, the workflow has a control gap regardless of how accurate the vendor claims to be.