How to design a B2B data freshness policy without overwriting decisions.

The direct answer

Refresh a B2B field only when you can name the decision that becomes unsafe as it ages, the source and cadence suited to that field, and the action required when the new result differs from the old one. A schedule is not a freshness policy; it is only a way to run one configured research field again.

This Guide owns a field-level freshness SLA for a reviewed account list. It is not a CRM clean-up, identity-resolution, deduplication, writeback, or system-of-record design. For the broader pre-enrichment CRM control framework, read CRM hygiene before enrichment.

Keep the accepted commercial decision in a separate, manually governed field. Use scheduled enrichment only for a non-authoritative research field, then compare its result with the accepted decision in your existing review process. Otherwise a newer-looking result can be mistaken for a replacement for a deliberate qualification, territory choice, or account-owner judgment.

1. Classify fields by decision and change rate

Never put protected commercial states, suppression states, ownership, lifecycle stage, or legal decisions on an automatic research path merely because they may be stale. Those fields require their own authority and controls.

2. Write the change-decision log

For each refreshable field, define:

• purpose: the decision that needs current information;
• source classes: which sources can establish a change;
• cadence: event-driven, monthly, quarterly, or another reasoned interval;
• comparison: how the new value is compared with the previous accepted value;
• states: unchanged, proposed change, conflicting, no result, stale, review required;
• owner: who can accept a change;
• history: what source, date, version, and decision must remain visible; and
• action: what an accepted change permits or blocks.

Example: a quarterly “local operating site” field may surface a changed result when a company-controlled source adds or removes a target-country site. It should create a review task in the team’s existing ownership process, with the old and new evidence available for comparison.

3. Use risk to choose cadence

The European Commission describes accuracy as purpose-dependent and requires reasonable steps to keep personal data accurate and up to date for that purpose. This does not create a universal monthly refresh rule. It means a personal-data field used to decide a next-week action needs a different policy from a historical company-description field. European Commission: GDPR principles

Use an ordered rubric instead of a false-precise formula. First assess the impact if the field is stale. Then assess the likelihood of a material change before the field is reused. Finally assess how urgently the next use needs a current answer. A field that is high on all three deserves tighter review; it does not automatically deserve more automation. If the source is weak or impact is high, shorten the review window or require a second source rather than accelerating the run.

Use the field freshness SLA

Download the field-freshness SLA. For one field, name the affected decision, the separately governed accepted-decision field, the non-authoritative research field, policy version, research question, permitted evidence, change-evidence threshold, insufficient evidence, cadence, staleness threshold, no-result action, structured accepted-decision date, retained history, and review owner. The retained-history instruction names source date, observation date, research-run date, and accepted-decision date separately. The example keeps an operating-site decision separate from new public evidence; it does not route or approve a territory change.

4. Pilot the policy on one column

Start with one Sheet, one field, one owner, and one segment. Leadbase scheduled enrichment is attached to a configured column and records cadence, local time/time zone, next run, and run history. Its run states describe execution, not a promise that every row received a correct result. Leadbase: scheduled enrichment

Audit the first three runs. For each outcome, ask:

• Did a source-linked result reviewed against the field contract alter a real decision?
• Did a no-result remain visible rather than erase the prior evidence?
• Were conflicts routed to a person?
• Did the old value and its reason remain recoverable?
• Was the cadence justified by the field’s business use?

5. Define the four dates before anyone refreshes a field

Most refresh disputes are not really about one value. They are about a team mixing four different dates together:

They answer different questions. A page published last month might be observed today; a run may retrieve it tomorrow; the team may still decide that it does not change an accepted account decision. Storing only "last updated" hides that reasoning. At minimum, retain the source URL, source or observation date, the research-run date, and the reviewer decision date where the field affects a commercial action.

This also prevents a common false inference: a new run is not proof of a new fact. It is evidence that a research process ran at a particular time. A source may have changed, disappeared, been inaccessible, or remained unchanged. Your field contract must say which of those possibilities are distinguishable and which result requires a person to inspect the source.

Give every state an owner and a next move

Use a small state model rather than a vague "fresh/stale" label:

These are process labels, not an automatic Leadbase taxonomy. The important control is that a no-result does not silently become "unchanged", and that a proposed change does not silently become an accepted business update.

6. Work a bounded example before choosing a cadence

Assume a team sells into companies with an operational presence in a selected country. The team keeps two deliberately different columns:

• Accepted market eligibility — a manually governed decision used by the team; and
• Current operating-site evidence — a research field containing a dated source link and concise observation.

On 1 April, an official company location page supports a location in the target country. A reviewer accepts the account for a market-review queue and records the decision, source, and date. The field is scheduled quarterly because the next planned account review is quarterly; it is not scheduled because quarterly is universally correct.

On 1 July, a run returns no acceptable result. That outcome does not prove the location closed. The review record continues to show the April evidence and the July no-result. The policy might require the owner to recheck the original source manually, seek another permitted company-controlled source, or pause the account until the next review. Which choice is right depends on the cost of a wrong territory decision, not on the run status.

On 1 October, a company-controlled page explicitly removes the target-country location. Now the research field becomes a proposed change: old evidence, new evidence, both dates, and the stated difference are available to the owner. The owner may change market eligibility, retain it with a recorded reason, or ask for more evidence. The system has surfaced a reviewable change; it has not assigned a territory, updated a CRM, or declared the account ineligible.

The same design works for role-family hypotheses or company activity evidence. It is less suitable for a protected campaign status, legal basis, suppression record, or customer relationship state. Those fields belong to their governing systems and policies, even if research could discover related information.

7. Turn the SLA into a field contract, not a calendar reminder

The downloadable SLA is useful only when the wording is testable. For each row, write the contract in this order:

1. Decision at risk: "We use this evidence to decide whether the account enters the country-review queue." Avoid abstract goals such as "keep data current."
2. Research question: "Does an acceptable company-controlled source still show an operating location in the target country?" One question is easier to audit than several loosely related questions in one column.
3. Permitted evidence: name the source class, whether a second source is required for a change, and what is insufficient. A search snippet or an old directory might be a discovery lead, not a change-authorising source.
4. Expiry and cadence: specify the age at which the evidence is stale and why the planned cadence detects material change before the next use. An expiry may be shorter than the schedule when an owner needs an ad-hoc check.
5. Result handling: say exactly what unchanged, proposed change, conflict, no-result, and stale mean for the accepted decision. "Update it" is not a handling rule.
6. Authority and history: name the person or role who may accept a change, what is retained, and where the reason is recorded.

Ask a second reviewer to read the row and decide what they would do after a no-result and after conflicting sources. If they cannot answer consistently, the contract is not ready for a scheduled field.

8. Run a controlled three-cycle pilot

Do not begin with every enrichment field or every region. Select a bounded segment whose owner can review all exceptions. Before cycle one, record the baseline: how many rows have acceptable evidence, how many are already stale, what the current accepted-decision state is, and who owns disputed records.

After each run, review a sample of every outcome state rather than only the records that look changed. Use these questions:

• Was the result tied to the exact field question, or did it drift into a more general company summary?
• Did the stated source class actually meet the field contract?
• Could a different reviewer reproduce the proposed change from the retained links and dates?
• Did a no-result follow the agreed rule, rather than deleting, guessing, or marking the account as failed?
• Did any downstream team mistake a research result for an approved decision?

At the end of the third cycle, count proposed changes, accepted changes, rejected changes, conflicts, no-results, and stale records. These are not performance benchmarks. They are a way to see whether the field contract creates useful review work or merely repeated ambiguity. Expand only after the team has adjusted source rules, cadence, or ownership based on that evidence.

9. Keep this policy separate from adjacent workflows

A freshness policy starts after an account and its governing decision fields already exist. It does not decide whether a company belongs in the ICP, replace deduplication, or make an outbound action permissible. If a proposed change means an account should be requalified, pass the preserved evidence to that review process. If it changes an account's handoff readiness, use the research-to-outbound contract to decide what the recipient may do. The policy's job is narrower: make one aging research field reviewable without pretending that recency alone is authority.

10. Test the policy against predictable failure modes

Before release, run five thought experiments with the field owner. They expose gaps that a normal "did the job run?" check misses.

The last row is especially important. A research field can be recent and still be unaccepted. If a downstream view needs a single operational answer, design that view around the manually governed decision field and its version, not a newly returned summary. This is how a team avoids treating data freshness as a permission to replace judgment.

Decide what a successful policy looks like

Success is not "every value changed" or "every run succeeded." A healthy pilot may reveal that a field rarely changes, that a source class is too weak, or that the effort of frequent review exceeds the decision benefit. Mark the policy as ready only when reviewers can consistently explain: which evidence is current, which decision is accepted, what happens on uncertainty, and who owns the next exception. Revisit the contract whenever the ICP, market, source availability, or downstream decision changes.

11. Distinguish field maintenance from data quality as a whole

A list can look clean and still lack a useful freshness policy. For example, all domains may be formatted, all companies may be resolved, and all mandatory fields may be filled. That does not show whether operating-site evidence can support a territory decision today, or whether a role-family hypothesis still justifies the next research step. Overall data quality asks about completeness, consistency, and appropriate identity; this policy asks the narrower question of whether this research field may still support its defined decision.

The distinction prevents a second confusion too: a supported company fact and an accepted commercial state are not the same thing. A new site may matter for research without moving an account to a different territory queue. A new product page may change company context without deciding ICP fit or campaign eligibility. The field contract governs the first transition—from a source to a reviewable observation. The accountable person governs the second—from an observation to a business action.

12. Plan review capacity as part of the cadence

A field is not fresh because a system runs it often. It is controlled and current only when someone can review the exceptions within the agreed window. Before the pilot, estimate the likely number of exceptions per run, the average time for an evidence comparison, and who covers the field owner during absence. A monthly cadence with twelve unreviewed proposed changes is less useful than a quarterly cadence whose conflicts are resolved transparently within a few days.

Record this capacity rationale in the SLA. It is not a Leadbase service-level promise; it is a team decision: which review commitment can we reliably carry for this field? Reassess it when account volume, source quality, or the number of decision-makers changes. Otherwise a cadence that began sensibly becomes a backlog of unhandled exceptions.

13. Use a small release review instead of implicit approval

Before expanding a field from one pilot to more segments, show the completed SLA row to the field owner, the recipient of the decision, and at least one reviewer. This need not be a large governance meeting. It tests four concrete points: Is the decision precisely named? Are the source and expiry rule sufficient? Is the action for no-result or conflict explicit? Can the named owner actually carry it within the planned cadence?

Record the answers with a rule version and date. Without visible approval, a scheduled column is often later understood as "automatically current" even though nobody agreed how an exception would be treated. Recording the release does not create a product feature or replace legal review; it makes operational accountability for one bounded research question traceable.

Refresh evidence without surrendering the decision

The usual refresh project treats the newest value as the best value and lets an overwrite erase the question that produced it. Leadbase supports a safer and more useful separation: one scheduled column refreshes the research evidence; a separately governed field retains the accepted commercial decision.

Automation should tell your team what may have changed. It should not quietly decide what the change means.

The column keeps its defined prompt and selected context, runs on the chosen cadence, and exposes a history of completed, skipped, pending, dispatched, or failed runs. The team can compare the research result with the accepted decision and inspect Sheet history before changing a handoff. That is the operational control: freshness becomes an observable workflow around one field, not a periodic bulk rewrite of the account record.

This makes Leadbase particularly useful when the question is specific—whether a location, service, hiring pattern, or other public company fact still supports the next action—and when a change deserves review rather than blind propagation. Leadbase is not a master-data platform, compliance engine, routing system, or automatic truth layer; it should not own CRM authority, suppression, or protected commercial decisions. Set up one controlled field pilot and audit its first three runs before expanding it.

Policy release checklist

• The field has a named decision and owner.
• Previous value, source, and date remain visible.
• A new research result is compared with the accepted decision in the team’s review process.
• No result, conflict, and stale evidence have explicit actions.
• Cadence follows business risk, not a generic default.
• The first three runs are audited before expansion.