Resolve individual visitors to the account they belong to, so the buying committee shows up as one account rather than scattered anonymous leads
B2B buying is a committee sport, but most B2B stacks score and route individual leads in isolation, missing the account-level picture entirely. Four people from the same company research over two months, each shows up as a separate lead, none individually looks hot, and the stack never notices that an account is in-market because it never grouped the four. The unit that buys in B2B is the account, and a stack that cannot resolve individuals to accounts is reading the wrong unit.
Resolving to the account is mostly a matching problem (email domain to company, firmographic enrichment to account) with one edge that breaks naive implementations: the consumer domain. A prospect using a gmail address, or a company on a shared or generic domain, does not domain-match cleanly, and a system that assumes every email maps to a corporate account either drops these prospects or misassigns them. The recipe is medium-high readiness because the matching is tractable but the edge cases and the enrichment provenance are real work.
This recipe resolves individual visitors to the account they belong to, with explicit handling of the cases where domain matching fails.
Individuals resolved to accounts, so the buying committee appears as one in-market account rather than scattered cold leads. The metric is account resolution coverage: the share of relevant individuals correctly bound to an account, which is high for prospects on corporate domains and necessarily lower for those on consumer or generic domains. The value shows up downstream as account-level scoring that catches in-market accounts individual scoring misses, and as ABM and routing that treat the committee as one. The honest framing is that coverage is bounded by domain quality, and the recipe is about maximizing correct resolution while handling the unresolvable cleanly rather than forcing every email into an account.
The second outcome is the foundation for everything account-based: scoring, personalization, and activation all depend on this resolution being right.
A firmographic enrichment provider plus an identity layer that maintains the account graph and the lead-to-account binding. Composable stacks suit this because the account graph and the enrichment provenance need to be inspectable, and the resolution feeds scoring and activation across the stack. The capability that decides coverage is the matching logic plus the consumer-domain handling: corporate-domain matching is easy, and the value of a good implementation is in how it handles the gmail prospect, the shared-domain company, and the parent-subsidiary hierarchy that simple domain matching gets wrong.
Compare the tools on Martech Stack Builder
Identity or CDP ownership owns the lead-to-account binding rules, the account hierarchy handling, and the consumer-domain edge case. Data engineering owns the domain-matching and enrichment pipeline and the account graph. Marketing ops decides how account-level resolution feeds scoring, routing, and ABM. Legal covers the basis for firmographic overlay and domain-based identification, which in the EU is a real question even in B2B, despite the persistent folklore that B2B data is exempt. The recipe takes months because the enrichment integration, the hierarchy handling, and the consumer-domain edge all need real work, and because the account graph becomes infrastructure downstream recipes depend on. The corporate-domain happy path is quick; the edges are the work.
Work in this order. Settle the legal basis and the unmatched state before the graph fills up.
Household or account-level resolution covers steps 2 and 6, anonymous-to-known stitching step 5, third-party data overlay with provenance tracking steps 1 and 4, and identifier graph write step 3.
The first failure is forcing the consumer-domain match. A prospect on gmail, or a company on a shared domain, does not map to a corporate account, and a system that assumes every email does either drops these prospects or assigns them to the wrong account. The consumer-domain case has to route to an explicit unmatched or individual state rather than being squeezed into an account it does not belong to.
The second is the stale account hierarchy. B2B accounts have parent-subsidiary structures and buying committees that change, and a hierarchy maintained once and never updated leaves stale account-level signals informing decisions, grouping people into accounts that have reorganized or splitting a committee that consolidated. The hierarchy needs maintenance, not just initial setup.
The third is unprovenanced enrichment treated as truth. Firmographic data from a third party varies in accuracy and becomes the brand's responsibility once it lands, so resolution built on it without tracking provenance or accuracy degrades silently as the data ages, and cannot be cleanly removed when a contract ends. Provenance tracking keeps the account resolution defensible.
The Workshop works out with your team which of these matter for your stack right now, and what to do first: a 90-minute session with the people who own the decision.
The domain-matching plus enrichment that maximizes coverage, the consumer-domain handling that does not force wrong matches, the hierarchy maintenance that keeps accounts current, and the EU basis for firmographic identification: those are the decisions that turn scattered anonymous leads into the account-level view B2B actually buys on.
Did this recipe match your situation?Anonymous response. Sign up to leave a longer note tied to your account.
Connect the same person across phone, laptop, and tablet using signals you can stand behind, with an honest fallback when you cannot
Run identity resolution behind one service rather than each downstream system maintaining its own join logic, so a single resolution rule survives the next stack change
Normalize email at capture so [email protected], [email protected], and [email protected] all resolve to the same person, before they become three records