How to research B2B company facts in a reviewable Sheet.

The direct answer

Do not ask a system to “enrich the company.” Ask one question whose answer changes a defined decision, specify the sources and output state that make the answer usable, and preserve no-result or uncertainty when the evidence does not support a conclusion.

For example, “Does this company operate a customer-facing field-service team in the target country?” is a researchable company fact. “Tell us everything useful about the company” is not. The first has a decision, source classes, and failure conditions; the second produces prose that cannot be reviewed consistently.

This Guide covers new prospective accounts and one company-level research field. It does not replace CRM identity controls, contact verification, legal analysis, or a general web-research policy. Use how to choose B2B data fields to enrich first to decide whether a field deserves a pilot, and how to design a B2B data freshness policy for its later refresh rule.

1. Write a field contract before writing a prompt

The contract prevents prompt wording from becoming the hidden policy. It also means a reviewer can improve a failing field without guessing what the original request intended.

2. Make evidence and inference separate columns

Store an observation separately from the decision it informs.

An observed fact can justify a narrow conclusion. It does not prove budget, urgency, or purchase intent. When credible sources conflict, preserve the conflict and send it to review; do not pick the friendliest interpretation.

3. Test the field on difficult cases

Before running at scale, use a labelled 15–30-account set that includes:

• a clear positive with a current first-party source;
• an account with a similarly named but irrelevant service;
• a group where the evidence belongs to another subsidiary;
• a stale announcement;
• an account with no usable public evidence; and
• two sources that disagree.

Review the output against the contract. Count supported results, false support, no-result, conflicts, and reviewer minutes. A high completion rate is not quality if the field turns ambiguous language into confident conclusions.

4. Use explicit output states

The following states should lead to different actions:

Leadbase documents enrichment as a column workflow: you configure the question and context, run it against selected rows, and inspect the completed result. Treat any returned numeric confidence as a product signal to inspect, not as one of the team’s editorial outcome states. A field can finish without a usable result; that is a valid outcome, not an invitation to invent an answer. Leadbase: enrich data in a Sheet

5. Make review measurable

Track three measures: review completion rate (selected rows with a documented team-reviewed state—supported, not supported by permitted evidence, no result, conflicting, or stale—÷ selected rows), review burden (minutes ÷ review-complete outcomes), and evidence retention (evidence-bearing outcomes with source and date ÷ evidence-bearing outcomes). “Not supported” means only that the permitted evidence did not establish the fact; it is never a negative fact about the company. Review a random sample every time the source set, prompt, market, or decision rule changes.

Use the company-fact research contract

Download the company-fact research contract. This is a field-contract template, not a row-level execution or review ledger. Complete it before running research: a decision it supports, one question, permitted and insufficient source classes, a freshness window, output format, no-result rule, conflict rule, and reviewer. Retain the per-row outcome states, source/date evidence, reviewer decisions, and pilot metrics in the working Sheet. Test the contract on three deliberately awkward cases: a group page that names no local site, a directory that conflicts with the company website, and a missing result. That is how a field contract becomes an operational standard instead of a prompt template.

Where a field contains personal data, GDPR Article 5 requires accuracy and, where necessary, keeping it up to date for the purpose of processing. A company-fact field is usually an operational quality question rather than a personal-data use case, but the same source-date-and-purpose discipline is a useful analogy; a vague “verified” label is not. GDPR Article 5: principles relating to processing

6. Turn a vague research request into an answerable question

The fastest way to degrade a data field is to let several people use the same label for different questions. “Local presence,” “enterprise fit,” or “has service operations” may sound precise in a planning meeting, yet each can produce several incompatible answers. A field contract should make the question answerable from an observable source, not merely plausible to a reader.

Use this rewrite sequence:

The narrower wording can produce more no-results. That is usually a healthy trade: a precise no-result tells the team that the public evidence does not support the action. A broad phrase can produce a high completion rate by smuggling inference into the field.

Define the permitted inference once

Every contract needs a sentence beginning: “From this evidence, we may conclude only that …” For the field-service example, it could be: “From a current official page describing on-site commissioning in the target country, we may conclude that the page supports an on-site-service hypothesis for this account.” It must not conclude headcount, spend, urgency, a buying role, or intent.

This one sentence is a useful review control. If an analyst cannot state the limited conclusion, the field is probably trying to answer two questions at once. Split it into two fields or defer the second question until an account has passed the first gate.

7. Build a source hierarchy, then define exceptions

Source quality depends on the fact being researched. An official filing may establish a legal name but say little about current operations. A current careers page may suggest a location or function but does not prove scale. A third-party directory may be useful for discovery and still be insufficient for a final conclusion. The source hierarchy should be written for the field, not copied from a generic “trusted sources” list.

For a company operating-fact field, a practical hierarchy might look like this:

Do not solve uncertainty by adding every available source class. More sources can create more contradictions and more review burden. Instead, decide which source has the authority to establish the particular fact, which sources may corroborate it, and which sources only create a follow-up. A directory that disagrees with a company page should not automatically be discarded; it should be recorded as a conflict signal and assigned a review action.

Quote the smallest useful evidence

An evidence note should preserve enough context for a reviewer to assess the claim without copying a page. Prefer a short factual observation, such as “Careers page lists a service technician role in Milan; checked 2026-08-08,” plus the URL. Avoid a long paraphrase that blends what the source said with what the researcher believes it means. Store the date because web pages change; a URL alone does not preserve the observed state.

8. Separate research output from decision ownership

A research field can inform a decision without owning it. This prevents automation from becoming an unobserved routing mechanism. Give each column a job:

In a small team, one person may hold several roles. The columns should still remain separate. A reviewer should be able to see whether a conclusion follows from the source or from a subsequent commercial judgement. This is particularly important when a field result is later exported, shared, or used by someone who did not run the original research.

A hypothetical review trace

This example is hypothetical and does not describe an actual company or Leadbase result. A row is selected because it meets a written ICP rule. The researcher asks whether an official source supports on-site maintenance in the target country. A current local service page mentions “commissioning and maintenance” but does not name a country; a current job post lists a service role in the country but is posted by the group. The correct outcome is conflicting or review needed, depending on the field contract—not “supported.” The commercial owner may decide to investigate the entity relationship. They may not treat the research text as evidence that a local buying team exists.

Now compare a different row: an official local site lists a target-country address and describes commissioning for the relevant product line, with a current date recorded. That can support the narrow local-service hypothesis. It still does not establish the number of technicians, budget, procurement process, or a contactable stakeholder. Keeping the conclusion narrow protects later outreach from a chain of unsupported assumptions.

9. Design a review queue that teaches the field

Not every result needs the same review. Create queues from the outcome state and the decision impact:

Set a maximum review time for the pilot. If an important field routinely exceeds it, the remedy may be a narrower source rule, a different decision point, or fewer rows—not a request for the model to sound more confident. Log rejection reasons in plain language. Examples include “group page only,” “dated source,” “product category too broad,” and “wrong legal entity.” After a sample of rows, these labels reveal whether the contract itself is flawed.

10. Calculate quality without rewarding confident prose

Completion rate measures whether a cell received output, not whether it supports a decision. Use a small scorecard that keeps error visible:

Pick thresholds before the pilot. For example, a team can decide that any review-rejected positive result in a high-impact field pauses scale until the source rule is corrected. That is a governance choice, not a universal benchmark. Do not compare the scorecard to a vendor’s generic “accuracy” statistic unless the field definition, source policy, population, and review method are comparable.

11. Preserve change history and expiry

Company facts age at different speeds. A legal identifier may be stable; a local site, product line, or service claim may change rapidly. Store both the observation date and an expiry/retest rule. “Current” is not a date, and a source first seen today is not automatically current for the decision.

When the contract changes, version it. State what changed: question wording, permitted source, freshness window, entity rule, output states, or next action. Re-review a small set of prior rows that the change would have affected. Otherwise a Sheet will mix results produced under incompatible policies while looking consistent on the surface.

Keep a small counterexample collection as well. For every field, include at least one over-broad marketing claim, group/subsidiary conflict, stale source, and clean no-result. New researchers and reviewers can use these cases to understand the rule; when the contract changes, retest these cases first. This creates an inspectable working definition rather than a silent change in what “supported” means.

Research boundary

This guide describes a repeatable way to investigate a narrow public company fact. It is not legal advice, a claim that public data is complete, a method for inferring individual intent, or a substitute for direct confirmation where a decision requires it. The right answer can be “no result,” “conflicting,” or “do not use this field for that decision.” Those outcomes are evidence of a disciplined process, not failures to conceal.

Turn one business question into a durable field

Schema-based enrichment is straightforward when the requested field already exists in a provider’s data model. Real ICP decisions are often messier: Does this company provide on-site maintenance in the target country? Does this operating unit serve the segment we sell to? Those questions often end up in browser tabs and notes, where they cannot be rerun or reviewed consistently.

Leadbase turns the question itself into a structured column. The team chooses the account context, selects the rows, defines the answer it needs, and reviews the returned value, concise summary, confidence signal, and source links. If the evidence does not support a reliable answer, no-result can remain visible instead of being replaced by persuasive prose.

What makes the result durable: the answer becomes a field the team can filter, review, rerun, and keep beside the account decision.

That is how one-off research becomes an operating asset. Your team can add its own review states—supported, not supported by permitted evidence, conflicting, stale, or no-result. Leadbase does not automatically decide those labels or guarantee that every public source is complete. Start a focused field pilot when the same business question is currently being answered repeatedly in private notes.

Field-release checklist

• The question changes a named decision.
• Permitted and insufficient source types are written down.
• Observation, inference, source, date, and decision are separate.
• No result, stale, and conflict have different actions.
• A difficult sample was reviewed before scale.
• The field has an owner and a retest trigger.