The direct answer
Enrich the field that resolves the next irreversible or expensive decision—not the field that is easiest to buy or most empty in a spreadsheet. Rank each eligible candidate field by decision impact, realistic availability and evidence route, volatility urgency, review cost, and policy or operating risk. Treat purpose, owner, necessity, a plausible permitted evidence route, and a safe no-result fallback as hard gates before anything is scored.
“More complete records” is not a business case. A company domain may prevent a duplicate merge; a local operating site may decide territory; a role may decide whether account research continues. A personal phone number may add cost and risk without changing any approved action. Those fields do not deserve the same priority.
1. Make a field-priority matrix
Score every eligible candidate field that has passed the hard gates from 1–5 before you request any results.
A field does not enter the score if its purpose is undefined, no accountable owner exists, the intended use has unresolved legal or policy questions, a personal-data field is not necessary and proportionate to that purpose, there is no plausible permitted evidence route, or no-result has no safe fallback. The availability score expresses uncertainty among fields that have such a route; it does not rescue a field with no route at all. The highest score is a pilot candidate, not an automatic production field.
2. Start with the action, then name the field
For personal-data fields, data minimisation is practical selection discipline. The European Commission says processing should be limited to personal data necessary for the specified purpose. That asks a simple question: if this field comes back empty, what decision changes? If the answer is “none,” do not make it the first enrichment request. European Commission: GDPR principles
3. Run a bounded, operational 30-row pilot
For each selected field, pick 30 already-approved accounts across the difficult parts of the segment. Thirty is an operational pilot size for exposing workflow failures; it is not a statistical minimum or a claim about market-wide performance. The matrix ranks candidate fields; its pilot_rows = 30 is the per-field account sample, not a requirement to name 30 candidate fields. Freeze the field definition, context columns, permitted sources, output state, maximum reviewer minutes, and the action that a usable result enables.
For each row, record found/supported, no result, conflicting, stale, incorrect, or not applicable. Calculate:
- usable yield = results that pass the written acceptance rule ÷ selected rows;
- review minutes per usable result = reviewer time ÷ usable results; and
- decision-use rate = rows where the named next action actually used the field ÷ selected rows.
Do not count returned text as usable merely because it fills a cell.
Use the field-priority matrix
Download the field-priority matrix. First apply the hard gates, including a plausible permitted evidence route; then score each eligible field from 1–5 for decision impact, availability and evidence route, volatility urgency, review cost, and policy or operating risk. The included model calculates impact + availability + volatility urgency − review cost − risk only when purpose_defined=yes, accountable_owner is populated, personal-data necessity is yes or not_applicable, policy questions are resolved, a safe no-result fallback is populated, the evidence route is plausible, and hard_gate_passed=pass. Duplicate the prepared sample row once for every candidate field you want to compare (up to 30); pilot_rows = 30 is the account sample for each field selected to pilot, not the number of fields readers must list. It is a transparent decision aid, not a vendor quality score; change the weights when a wrong value would be costly.
4. Treat contact fields as a second decision
Email and phone lookup should not be the default next step after an account is discovered. First state the role, purpose, country, channel gate, and fallback when no contact is available. Then request the smallest field set needed for that next decision. A current-looking contact value is not proof that the account is right, the role is relevant, or outreach is permitted.
Treat a dedicated direct email or phone lookup as a separate, stateful result from a research-column result. Review a research-column result as a value or visible no-result with its confidence and source links; do not label every found contact “verified.”
When the matrix genuinely selects a contact field, move into the matching operating contract rather than broadening this pilot: use the work-email Guide for email identity and verification layers, or the direct-phone Guide for bounded phone lookup and call-readiness review.
Estimate the cost of qualifying before contact lookup
The interactive planner below compares two contact-lookup paths only: looking up contacts for every candidate account, or first limiting lookup to accounts that passed qualification. It does not rank enrichment fields, establish a market price, or promise a Leadbase saving. Use your own lookup cost and expected availability to decide whether this second decision deserves a pilot.
Compare qualification-first contact lookup
Compare buying contact lookups for every candidate with qualifying accounts first and looking up contacts only for the accepted group.
Use your own pricing and observed rates. A contact result can be available without being relevant, current, or permitted for the intended use.
Under these assumptions, 70 accounts reach contact lookup. That avoids 260 lookup attempts and €260.00 of marginal scenario cost.
| Metric | Lookup every candidate first | Qualify accounts first |
|---|---|---|
| Contact lookup attempts | 400 | 140 |
| Estimated available contact results | 280 | 98 |
| Illustrative lookup cost | €400.00 | €140.00 |
The comparison holds contacts per account, unit cost, and availability constant. Only the number of accounts sent to contact lookup changes.
Lookup-first multiplies every candidate account by contacts requested per account. Qualify-first applies the account qualification rate before that multiplication. Both scenarios use the same marginal unit cost and expected available-result rate.
This is planning arithmetic, not Leadbase pricing or a savings promise. Qualification has its own cost, and actual lookup availability and relevance must be measured in the intended segment.
5. Inventory decisions before you inventory data
Teams often start field planning with a list of what is missing: industry, headcount, funding, technologies, contacts, phone numbers, revenue, intent, locations. That approach makes the most visible gaps look important. Start instead with the decisions that occur between a candidate account and a next step. A field is valuable only when it reduces uncertainty at one of those decisions.
Make a decision inventory with the people who own the workflow:
The table makes a useful distinction: some fields identify an account, some describe it, and some are inputs to a policy or human decision. Do not combine them. A canonical domain can help resolve identity but cannot prove a territory. A local address can support a location review but cannot prove a buyer exists. Keeping these roles separate means you can stop an over-broad enrichment request before it accumulates data with no owner.
Give every proposed field a one-sentence job
Use the format: “This field is collected only to help role decide action under rule; if it is unavailable, fallback applies.”
For example: “Local operating-site evidence is collected only to help the territory owner decide whether a reviewed account belongs in the target-country queue under the operating-site rule; if it is unavailable, the account remains in review.” That sentence is more useful than “location enrichment.” It makes the purpose, owner, acceptance rule, and no-result outcome visible.
If a proposed field cannot be written this way, it is usually one of four things: generic context, a disguised future use, a derived score with no accountable owner, or a request that should be split into smaller questions. Park it rather than adding it to the first pilot.
6. Score fields with a visible trade-off, not a magic total
A matrix is a conversation aid. Its score should expose why one field won, not create the illusion that a spreadsheet has selected the truth. Score each criterion independently, then write a short reason beside it. A score without a reason cannot be reviewed when the market or policy changes.
One useful ordering is:
- Hard gates first. A field cannot proceed if its purpose is undefined, its owner is missing, its proposed use has unresolved policy questions, it has no plausible permitted evidence route, or it would overwrite an accepted business decision without a review rule.
- Decision impact second. Among fields that clear the gates, prefer the one that changes a named decision in the next workflow stage.
- Evidence and reviewability third. A high-impact field that cannot be supported or reviewed reliably is not automatically a good first field; it may need a manual research design instead.
- Operational cost fourth. Compare expected no-result, reviewer minutes, refresh burden, and the number of rows eligible for the request.
Work a hypothetical prioritisation example
This example is hypothetical. The numbers are not product performance, a legal assessment, or a recommendation for every team.
An account team is deciding among four requests for 30 already-approved companies: canonical domain, local operating-site evidence, a broad “technology stack” label, and a decision-maker phone number. It gives each field a 1–5 score and writes a reason.
The canonical domain may win the first pilot even though it is not the most exciting field. It removes a blocking identity error and has a clear fallback. The operating-site field can be the second pilot after the team writes its country rule. The technology label is deferred because “technology stack” is not an observable, decision-specific question. The phone-number request is held because a value alone does not establish role relevance, permitted use, or a channel decision.
The point is not the arithmetic. A different team could legitimately give operating-site evidence the first priority if territory assignment is blocking a launch. The matrix makes that disagreement explicit. It should never be used to claim that a field is universally high quality or legally appropriate.
7. Define an acceptance rule before selecting rows
“Found” is not an acceptance rule. For every pilot field, specify what makes an outcome usable and what happens otherwise. Use a compact acceptance card:
The acceptance card turns a vague request into a pilot that can fail cleanly. If only five of 30 rows are usable, that is a result. It may mean the source policy is too strict for the intended market, the field is not available publicly, or the decision should not depend on that field. Do not “solve” it by quietly broadening the evidence after results arrive.
8. Choose the right field family
Not all fields behave alike. Applying one refresh cadence, source rule, or success measure to every field guarantees confusion. Classify fields before measuring them.
This classification also explains why a single “complete profile” request is a poor pilot. It combines identity, qualification, contact, and derived analysis fields with different evidence standards. Start with one family and one decision. The result can later inform a controlled next field, but it should not trigger a chain of automatic data collection.
9. Build no-result and error economics into the pilot
No-result is often treated as wasted effort, so teams select only easy rows or count plausible text as success. That produces a misleading picture of what the workflow will cost at scale. Record no-result as a first-class outcome and distinguish it from incorrect, conflicting, stale, and not-applicable outcomes.
Before the pilot, set a budget in reviewer minutes and a stopping rule. For example: pause if a high-impact field produces any incorrect positive in the reviewed sample; narrow the rule if conflicts exceed a team-defined threshold; stop if no-result has no safe fallback. These are not universal benchmarks. They are safeguards against turning a pilot into an open-ended data purchase.
Test the difficult rows on purpose
Do not choose 30 clean, well-known companies. Include records with a group/branch relationship, a non-English site, a likely distributor, a formerly active company, missing website evidence, and a company near the size boundary. These are where a field definition either carries its weight or breaks. Label the sample as deliberately difficult so no one later treats its yield as a national benchmark.
10. Make refresh a property of the decision, not the database
The question is not “How often can we refresh?” It is “When would a stale value change the decision enough to justify another check?” A field used only to resolve an identity once may need no recurring refresh. A local operating claim used to route new accounts may need a dated review rule. A commercial decision remains a human-owned record even when its supporting research is refreshed.
Create a short freshness policy per field: observation date, expiry trigger, source class, eligible rows, reviewer, and what must never be overwritten automatically. For a volatile research field, a scheduled Leadbase column can run against the configured research question and retain run history; it does not approve changes, establish a master record, or route ownership for you. Compare a new research outcome with the accepted decision in your existing review process.
11. Use the matrix as a decision record
The downloadable field-priority matrix should be more than a ranking tab. Keep the following alongside each field: the decision it supports, score reasons, hard-gate result, field owner, permitted evidence, pilot population, reviewer-time budget, no-result fallback, scale/stop decision, and retest trigger. The artifact has explicit columns for each of these decision-record fields. When a stakeholder later asks why the team enriched a location field before a contact field, the answer should be visible without reconstructing it from a meeting.
Boundary of this guide
This framework helps a team decide which narrowly defined company or contact-related research field to test first. It does not determine a lawful basis, replace data-protection or procurement advice, promise data availability, or make a found value accurate for every purpose. Its strongest outcome is sometimes a documented decision not to collect a field at all.
Before expansion, the field owner should be able to repeat the pilot decision in one sentence: which field, for which decision, on which rows, under which acceptance rule, and with which stop trigger. If any part is missing, the next useful work is not broader enrichment but a clearer operating definition. This short check prevents an apparently successful test from quietly becoming blanket data collection.
The Leadbase idea: create the field your ICP needs
Schema-based enrichment begins with the fields a provider already has. Leadbase enables the more valuable question: Which answer would let us identify the companies we actually mean? That is the difference between accepting a vendor's taxonomy and adding your own market logic to the list.
In Leadbase, a publicly researchable business question can become a structured, filterable field across the market.
The team defines one target column, gives it only the relevant Sheet context, selects the approved rows, and reviews the returned value, concise summary, confidence signal, and source links. If the research cannot establish a reliable answer, the row can remain a visible no-result. The question, evidence, and uncertainty therefore stay attached to the account instead of vanishing inside a bulk append.
That design creates a practical advantage over data-completion-first workflows: a costly personal field does not run merely because it is empty, and a niche company criterion does not need to exist as a prebuilt provider field before the team can research it as a structured column. You spend effort where an answer can change selection, routing, or the next approved action.
Leadbase does not choose your lawful basis, field owner, acceptance rule, or overwrite policy. It gives those decisions a focused execution surface. Run a 30-row field pilot only after you can finish this sentence: “If this field returns a usable answer, we will ___.”
Stop or scale
Scale only if the pilot clears a pre-set usable-yield and review-time threshold, produces a visible action change, and does not create unresolved policy issues. Otherwise narrow the field, improve the source rule, choose a different decision, or stop. A no-result that saves a costly wrong action can be more valuable than a plausible fill.
