Enriching CRM accounts from the public web, field by field

Enriching CRM accounts sounds like a data-entry problem: find the missing industry, headcount and headquarters, fill the blanks, move on. In practice the hard part is not finding values. It is knowing where each value came from, when it was true, and whether anyone checked it before it changed how an account is routed or approached. This guide covers which fields are worth enriching from public web information, how to keep provenance for every field, how often to refresh, how to review changes before they land in the CRM, and how to choose data sources for sales tools in the first place.

Start from the decision, not the field list

Every enriched field should change something a person or a system does. If you cannot name the decision, the field is decoration, and decoration still costs money, goes stale and confuses reps.

Write the decisions down first. A few typical ones:

• Routing: accounts headquartered in a given region go to that region's team.
• Prioritization: accounts that are actively hiring for finance operations move up the list.
• Messaging: accounts that already run a competing product get a different first email.
• Disqualification: accounts below a size range, or in an excluded industry, leave the queue.

Each decision names the fields it needs and, just as important, how wrong a value can be before it matters. A headcount range that is off by one band rarely changes routing. A wrong country does.

Fields worth enriching, and ones that rarely are

Fields that rarely earn their place: revenue figures with no source (often a modeled estimate presented as fact), scores you cannot trace back to an input, and vanity metrics such as follower counts. If a field cannot carry a source, it should not carry weight in a decision.

Provenance for every field, not every record

Most enrichment setups record provenance at the record level, if at all: "enriched by vendor X on some date". That is not enough. Within one account, the country may come from an official registry, the headcount from a careers page and the technology from a job posting, each with a different age and reliability. Store provenance next to each value.

{
  "account":   "example.com",
  "field":     "hq_country",
  "value":     "Germany",
  "source":    "https://example.com/imprint",
  "retrieved": "YYYY-MM-DD",
  "evidence":  "Registered office: Musterstrasse 1, Berlin",
  "method":    "extracted",
  "status":    "confirmed"
}

Two of those fields do most of the work. evidence is the passage that supports the value, so a rep can check it in seconds without opening a browser. status separates a confirmed value from an inferred one and from unknown. Unknown is a legitimate answer. A blank cell that means "we looked and found nothing" is different from one that means "we never looked", and both are better than a plausible guess.

Per-field provenance also pays off later: when a rep disputes a value, when you want to refresh only what has aged, and when someone asks where a piece of information about them came from.

Refresh cadence by field

One global refresh schedule either wastes effort on stable fields or lets volatile ones rot. Set the cadence per field instead.

• Stable fields (domain, legal name, country, industry): recheck on a slow cycle, or when something signals a change, such as a redirect to a new domain.
• Moderate fields (headcount range, technology): recheck periodically for accounts in active stages; leave dormant accounts alone.
• Events (new funding, a new office, a leadership change): never overwrite. Append each event with its date and source, and let the history speak.
• Contacts: re-verify immediately before outreach, not on a calendar.

For event fields, monitoring beats bulk refreshing. A monitoring rule should be specific enough that a person could run it by hand:

watch     careers page and newsroom of accounts in stage "target"
question  has the company opened a role in procurement or finance operations?
material  a new posting, or a posting removed; ignore wording edits
cadence   weekly, Monday 09:00, Europe/Istanbul
notify    email the account owner; do not write to the CRM automatically

The last line matters. A detected change is a reason to look, not a reason to act. For choosing which signals deserve a rule at all, see sales trigger monitoring.

Review before anything reaches the CRM

Writing into a CRM is not a neutral act. It overwrites values someone may have corrected by hand, it can start sequences and routing rules, and bad data spreads into reports before anyone notices. Treat enrichment output as a proposal until someone accepts it.

1. Stage the results in a review table outside the CRM: current value, proposed value, evidence and status side by side.
2. Flag every case where a proposed value would replace one a person entered. Those need an explicit decision, never a silent overwrite.
3. Spot-check a sample of each batch against the evidence column before accepting the batch.
4. Accept per field or per batch, and record who accepted what.
5. Write unknowns as unknown. Do not let a sync job turn "no source found" into an empty string that looks like a real value.

This sounds slow, but most of the review is reading a diff. The cost of skipping it shows up later, as reps who stop trusting the CRM and start keeping their own spreadsheets.

Choosing data sources for sales tools

No single source covers every field well. Most teams end up combining a few, and the useful question for each is what it is good for.

• Commercial company and contact data providers. Large ready-made databases of firmographics and contacts. Check whether they expose a source and date for each value, how they collect contact data, what their terms allow you to store in your CRM, and what happens to stored data when the contract ends.
• Web search APIs. Fresh discovery across the open web; you still have to read pages and extract values. See the guide to choosing a web search API.
• Scraping and extraction tools. Structured values from pages you already know, such as an imprint or a careers page. Respect site terms and robots rules; the scraping API guide covers the trade-offs.
• Official registries and filings. Authoritative for legal name, address and registration status; slow or silent on everything else.
• Your own first-party data. Product usage, support history, past deals. Often the strongest signal you have, and the one teams most often forget to join.

Evaluate any candidate on your own accounts rather than on a vendor demo. Take a sample of accounts your team knows well, enrich them, and check every field by hand against what you know. Count how many values are right, wrong, stale and unknown, and look closely at your own territories, because coverage is rarely even. Contact data deserves extra care: it is personal data under laws such as the GDPR and Turkey's KVKK, so confirm your lawful basis with counsel before you store it. For a wider look at providers and integration patterns, see data enrichment APIs.

Where GoCux fits

GoCux does not crawl or search the open web, so it is not an enrichment provider. Its job is the part after collection: turning source material into values you can check, and keeping the result reviewable. Web pages come in only through an authorized browsing or export step, and when they are imported they keep their original page reference and the date they were retrieved.

From there, Extraction pulls values from the documents you provide and attaches to each one the passage it rests on, leaving a missing value as unknown instead of a guess. FindAll takes your matching criteria and columns and returns a table in which every row carries its evidence, and it reports coverage limits rather than hiding them. Pulse runs a recurring question over sources you choose and presents each change for review; a detected change never acts on its own. Exporting data is one of the actions that pause for a person, with the files in scope listed. The sales solution page shows how these pieces fit together for account research.

Checklist before your first enrichment run

• Every field on the list maps to a written decision.
• Each value will be stored with source, retrieval date, evidence and status.
• "Unknown" is a permitted value, and your sync will not turn it into a blank.
• Each field has its own refresh cadence; events are appended, never overwritten.
• Results are staged and reviewed before any CRM write, and values entered by people are protected.
• Candidate sources were tested on a sample of your own accounts and checked by hand.
• You know what each provider's terms allow you to keep, and for how long.
• Personal data has a lawful basis and a named owner.