Account intelligence: an enterprise operating guide for RevOps

What account intelligence should answer

An account record is useful only when it helps someone make a defined decision. A territory-planning workflow may need country, employee range and group ownership. An account executive preparing for a meeting may need current stakeholders, open opportunities, product usage and a recent company event. An AI research workflow may need the same facts, but also machine-readable evidence and an explicit stop when the company cannot be resolved.

That is why account intelligence is broader than company enrichment but narrower than “everything known about a business”. Company enrichment appends available facts to a company record. Contact enrichment retrieves available professional identity and contact fields. Intent or change signals describe time-bound activity. First-party CRM information records your organisation’s own relationship. Account intelligence joins only the evidence required for a decision and preserves the difference between those layers.

Demandbase’s account-intelligence guide, updated 18 September 2026, describes a combination of first-party CRM, marketing and engagement data with third-party firmographic, contact, hierarchy, intent and technographic information. Other products use the same label for different problems. Pylon applies it to post-sale conversations and customer signals, while Salesforce provides an Account Intelligence view inside its own sales workflow. The shared label does not create a shared data contract.

Before buying or building anything, state the output in operational language: “select accounts for the Nordics enterprise campaign”, “prepare a briefing for an existing customer”, or “route a new enquiry without overriding a named-account owner”. If the output is simply “give sellers more insight”, the project has no measurable acceptance rule.

Build three layers: identity, evidence and decision

A dependable account-intelligence system separates three layers. The identity layer decides which company the record represents. The evidence layer stores facts, people, observations and their dates. The decision layer applies the organisation’s current rules. Keeping them separate prevents a changed score from rewriting the underlying evidence and prevents a newly retrieved domain from silently replacing a reviewed account match.

Do not use the CRM company name as the sole identity key. Trading names change, domains are shared, subsidiaries operate under a parent brand, and several legal entities can use one website. A strong exact identifier may be sufficient for automatic matching. A name-and-country match may be acceptable in one market but ambiguous in another. A bare domain often identifies an operating brand rather than the entity that contracts, invoices or owns the relationship.

The same discipline applies to people. A contact found at a company is not necessarily part of the buying group, and a working email does not establish current employment. Preserve person identity, employer association, role relevance and contactability as separate claims. If the workflow needs a finance decision-maker, “senior employee found” is not an acceptable substitute.

Define B2B account intelligence research methods before choosing fields

Enterprise account research is a method, not a browser tab. Begin with a question, choose the evidence classes that can answer it, then set the acceptance and expiry rules. This reverses the common approach of collecting every available field and hoping a seller will infer what matters.

For account selection, stable company facts normally come first: identity, country, industry, size, operating status and corporate relationships. For meeting preparation, add first-party opportunity history, recent interactions and named stakeholders. For timing, add a narrowly defined change event such as a leadership move, hiring pattern, filing, funding event or product announcement. The event must have a date and a reason it changes the decision.

Technographic information can be valuable, but a detected technology does not prove current paid usage, contract size, satisfaction or replacement intent. Teams comparing the best account intelligence platforms for technographic data in B2B should ask how the technology was observed, when it was last seen, whether historical observations are retained and how conflicting evidence is handled. A product badge on a website and a procurement record are not equivalent observations.

Separate direct evidence from interpretation. “The company published 34 engineering vacancies in September” is an observation. “The company is expanding its data platform” is an inference. “Contact the VP Engineering now” is a recommendation. Store the three statements separately so a reviewer can disagree with the inference without deleting the underlying observation.

Resolve the account before enriching it

An account intelligence API cannot repair a vague subject by adding more attributes to the wrong record. Resolve identity first, then enrich. The practical input order is strongest identifier, domain plus country, exact company name plus country, and finally a candidate search that requires selection. Never accept the first fuzzy candidate simply because the response has many populated fields.

Set match thresholds by consequence. A campaign-segmentation job can tolerate more review than an automated ownership change. A high-value named account should not be merged automatically from a weak domain match. The illustrative threshold model below shows the trade-off: increasing the score required for an automatic match reduces false-match risk in the model, but sends more records to review or leaves them unresolved.

Confidence scores from different providers are not automatically comparable. One may represent similarity between name and domain; another may combine several hidden signals. Keep the original score and method name, then map it into your own policy only after testing. Do not average two opaque scores and call the result stronger evidence.

Preserve candidate lists for rejected automatic matches. When a human selects a candidate, record who approved it, the evidence used and whether that decision should survive future refreshes. A later enrichment run should not undo a reviewed match merely because a field changed.

Design the account intelligence API contract around evidence

An account intelligence API should return more than a convenient summary. The integration needs a stable subject identifier, field-level values, explicit missing states, relevant dates and enough provenance to understand what can be trusted. A single `complete: true` flag hides the decisions that matter.

Lusha’s current V3 documentation separates search from enrichment: search returns candidate previews and reveal costs, while enrichment returns fuller contact or company data. SalesIntel distinguishes targeted API enrichment from large-scale delivery through other methods. Similarweb exposes company, website, contact and signal data as separate capabilities. These product designs differ, but they illustrate a useful procurement question: can the buyer inspect identity and likely cost before committing to a full retrieval?

Use idempotent job identifiers for batch work. A timeout should not create a second account or spend twice without control. Return operational failures separately from “no data”. Authentication failed, supplier timed out, subject unresolved and verified absence are different states. Only the last two describe the record; the first two describe the request.

Measure cost per usable account, not cost per response

Nominal API price is only one part of account-intelligence economics. A response can be inexpensive yet unusable because the identity is ambiguous, a required field is missing, the signal is stale or no relevant person is available. Add the enrichment charge, supporting signal or contact lookups and the labour required to review exceptions, then divide by accounts that pass the agreed policy.

Assume a batch of 1,000 accounts costs £180 for company enrichment, £120 for contact lookup and £100 in allocated review time. Total operating cost is £400. At a 60% policy-usable rate, the team receives 600 usable accounts and pays about £0.67 per usable account. At 30%, the same batch costs about £1.33 per usable account. The API invoice has not changed; the denominator has.

Do the same for incremental layers. If technographic data adds £150 and changes the decision for only 20 accounts, its marginal cost is £7.50 per decision-changing account. That can still be sensible for valuable opportunities, but it should not be justified using overall record completeness. If a signal is used only for prioritisation, test whether removing it changes the ranked action list.

Provider-count claims do not answer this question. Multiple suppliers may overlap, repeat the same upstream observation or return fields the workflow does not need. Procurement should pay for unique decision value, not the maximum number of logos in a waterfall.

Apply freshness rules to each evidence class

One global “last updated” field is not enough. Legal identity, employee range, job title, email status, technology observation and intent signal decay at different speeds. Define a freshness policy per field and preserve both the evidence date and the retrieval date. When an observation date is unavailable, mark that limitation rather than substituting the API call time.

A company’s incorporation date does not expire. Its operating status can change. An annual revenue figure may remain the latest filed value even when it is more than a year old. A job move can invalidate a person-account association immediately. A news item remains historically true but may no longer justify current outreach. “Old” therefore means unsuitable for the current decision, not necessarily false.

Monitoring should trigger a review when decision-relevant evidence changes. It should not rewrite every downstream field automatically. A new employee estimate may change segmentation; a director change may affect a named stakeholder; a newly observed technology may only create a research task. Define the consequence by field and workflow.

Map the buying group without inventing authority

Account intelligence often aims to show a buying committee, but titles alone do not reveal decision rights. Start with roles relevant to the purchase: economic buyer, technical evaluator, daily user, security or compliance reviewer, procurement and potential blocker. Then map people to those roles using evidence available to your organisation.

Job title is a clue, not proof. A global company may centralise procurement while business units choose their own software. A senior technology leader may sponsor the programme without approving budget. A named contact in the CRM may be a former employee. Keep role hypothesis, person association, relationship evidence and contactability separate.

Measure coverage by required role, not number of contacts. Ten engineers do not compensate for a missing procurement stakeholder if the workflow requires procurement. Count unique people after deduplication and report unresolved roles explicitly. For an existing opportunity, first-party meeting and relationship evidence should normally outweigh a generic third-party title match.

Give AI agents bounded, inspectable account context

The market is moving from account dashboards towards systems that can act. ZoomInfo’s investor release dated 30 September 2026 says its DoubleO.ai acquisition combines agentic orchestration with GTM intelligence so agents can run multi-step motions with shared context. Apollo’s current MCP documentation exposes company search, company enrichment, job postings and people enrichment alongside actions that can update contacts, accounts and deals.

The operational implication is not that agents require more data. They require a smaller, explicit evidence package and tighter permissions. Give the agent a resolved account ID, accepted fields, dates, source class, unresolved conflicts and the exact action allowed. Keep credentials outside prompts, restrict write tools, require approval for material CRM changes and log the evidence used for each recommendation.

A summary should not replace the evidence package. If an agent says “hiring is accelerating”, the workflow should retain the vacancies or source observations, their dates, the comparison period and the rule that created the statement. If the evidence conflicts, the agent should surface the conflict or abstain rather than choose the most convenient value.

TargetWise supports company and contact retrieval through documented REST and MCP interfaces. That can supply available structured context to a workflow; it does not decide the buyer’s scoring policy, infer missing authority or authorise outreach. Keep those decisions in the surrounding application and approval process.

Use a controlled implementation sequence

1. Choose one decision. Start with a bounded workflow such as territory segmentation or meeting preparation, not a universal account-360 project.
2. Define the subject. Decide whether the account means a legal entity, operating brand, website domain, corporate group or CRM account.
3. List decision-changing fields. Remove fields that do not affect eligibility, priority, owner or next action.
4. Set acceptance and expiry rules. Define how identity, missing data, contradictions, dates and source classes are handled.
5. Build an evidence ledger. Store original values and dates before normalisation or summarisation.
6. Test an authorised sample. Include subsidiaries, shared domains, rebrands, stale contacts and conflicting providers.
7. Run in observation mode. Produce a proposed decision without writing it to the production CRM.
8. Audit errors and economics. Measure false matches, review load, latency, field-level coverage and cost per usable account.
9. Enable narrow writes. Protect reviewed identifiers and relationship ownership; make every update reversible.
10. Monitor drift. Recheck rules when inputs, suppliers, schemas or business policies change.

Do not declare success from overall match rate. A system can match many domains and still select the wrong subsidiary. It can return many contacts and miss the required role. It can produce a persuasive brief from stale facts. Audit the precise errors that would change a business decision.

Procurement questions for account intelligence platforms

Run the evaluation on records that represent the actual markets, account types and failure cases. Do not allow the supplier to remove every ambiguous entity or stale contact from the sample. Agree the denominator before the test begins and preserve unresolved outcomes in the results.

Set pilot acceptance rules before seeing the results

Use a small, representative pilot to make the buying decision concrete. For example, an enterprise team could assess 200 authorised accounts across its target countries, including shared domains, subsidiaries and records with missing identifiers. This is an illustrative evaluation design, not a statistically representative benchmark. Keep one reviewed reference set and apply the same input records and field requirements to each supplier.

Have reviewers adjudicate identity independently of the supplier's score. Report wrong automatic matches as a share of all automatic matches, unresolved accounts as a share of all inputs, and required-field coverage on the correctly resolved accounts. Audit stale employment separately from email verification. A high field-fill rate should never hide incorrect company associations.

Agree pass, review and stop rules before the test. Set the tolerated false-match rate according to the consequence of a wrong entity; set a review workload that the operations team can actually handle; and set a maximum cost per usable account that the workflow budget supports. If any of these limits fails, keep the workflow in observation mode and change the matching policy, evidence requirements or supplier choice. A zero-error result on a small sample does not establish zero production risk.

Measure the business effect separately from retrieval quality. For territory planning, compare reviewed eligibility decisions and incorrect assignments. For meeting preparation, ask whether the brief contains accurate, decision-relevant facts that the seller could use. Pipeline or revenue claims need an agreed comparison period and attribution method; more complete records alone do not prove incremental revenue.

Control permitted use and contact-data access

Company facts and named-person contact details need different access rules. Before connecting a supplier, establish which fields each team or agent needs, which uses the contract permits, how long records can be retained, and who handles correction, deletion and suppression requests. Treat these as documented procurement and implementation decisions, rather than inferring permission from the fact that an API returned a value.

A verified business email establishes a contactability claim; it does not establish permission to contact the person. Keep your organisation's approved outreach rules and suppression controls in the sending workflow. If several providers return the same person, a suppression or reviewed correction should survive deduplication and future enrichment instead of being overwritten by the next response.

Restrict personal fields by role, avoid copying full contact records into general-purpose prompts or logs, and record exports and material changes. Test that a suppressed record stays suppressed after a refresh, that a reviewed employer correction is retained, and that an agent cannot disclose fields outside its approved scope. Ask the supplier to document processing locations, subprocessors, retention and downstream-use rights; do not assume these are identical across products or contract tiers.

Frequently asked questions