ICP & TAM Mapping

Who does what

• GTM Lead owns the request, the ICP sign off, the capacity and the approval.
• List Builder a GTM engineer or someone in RevOps, builds the list and the scores.
• Reviewer a sales lead, judges samples, edge cases and dream accounts.
• Privacy Lead a DPO or counsel, checks the channel plans per market.
• CRM Admin owns the account fields, duplicate rules and publishing to the CRM.

What you need

• Won and lost deals, or people you can interview when you have none yet.
• Your offer, your markets and your team's capacity.
• The data tools you have licensed, with API keys and a budget cap.

Some answers are yours to set before the first run:

• How many deals count as evidence.
• Whether the parent company or the local entity is the account.
• How many people, weekly hours and touches each tier gets.
• What spot check agreement and backtest separation are good enough.

1Define the fit

• Request a TAM map
• Have won deals?
• Study won and lost deals
• Build a fit hypothesis
• Write down who fits

The GTM Lead opens the run with a scope. When a map already exists, you refresh its version and keep what still holds.

• The offer, the markets and the segment in question.
• The team's capacity in people and weekly hours.
• A budget cap, agreed before anything is pulled.

The first decision asks whether you have won deals to learn from. With real evidence, meaning won and lost deals in the segment with value and loss reason, the List Builder exports both piles from the last one or two years, enriches them with the same fields and keeps the attributes that are far more common in wins than in losses. Deals lost only on timing stay out, since they say nothing about fit. Three test lists come out of this step and come back later to test the score:

• Best customers.
• Bad fits.
• A random sample of the market.

Without that history, the GTM Lead builds a fit hypothesis instead. Interviews ask about the last time the problem hit and who owns it, and never pitch. Design partners, competitors' published customers and repeated job posts for the role your offer helps become the seeds. The result is two or three narrow segments, each with a buyer, a trigger and disqualifiers, labelled as a hypothesis so the map stays at pilot size.

Both paths meet in one document, the ICP. It gets a date and a version, and its rules follow a few principles:

• Hard filters, disqualifiers and scored criteria stay apart.
• Every rule names the data field it reads, and two people classify the same company the same way.
• Questions no database can answer become one closed website question.
• Timing signals such as funding or hiring stay out of the fit rules unless the backtest earns them.

2Build the list

• Pull companies from several sources
• Merge and remove duplicates

With the rules set, the List Builder pulls companies from several kinds of source. Before each pull you count the segment and test the source on your known customers. The share of them it finds is its coverage.

• A filter database such as Clay.
• A lookalike source like Ocean.io, seeded with your best customers.
• For DACH, a company register such as North Data.

Search tools cap their results, so a count that lands on a cap means the pull was cut and needs splitting:

• Clay Find Companies, AI Ark and DiscoLike return 10,000 companies per query.
• Apollo shows up to 50,000.
• A Clay table stops at 50,000 rows without a warning.

Every row keeps its source, query and date, and LinkedIn is researched by hand only. The merge then reduces the rows to one per real company. Domains are normalized, redirects followed, parent companies mapped with DiscoLike, and every company is matched against the CRM, so customers, open deals and owned accounts stay in the list with their status.

3Check every company

• Check each website with AI
• Does the company fit?
• Add size, stack and funding

Some fit questions only a company's own website can answer. An agent step in Clay asks the website question for each account and answers yes, no or unclear, with the URL of the page it relied on and a one line reason. You test it on ten known accounts against the Reviewer first, and a person opens the cited pages for a sample of every batch.

The second decision follows: does the company fit? It fits when every hard filter passes and the website check says yes. Any of these takes it out:

• A disqualifier.
• A no from the website check.
• A closed company.
• An excluded CRM status.

An unclear answer never passes on its own, and overrides are logged with who made them, why, and the evidence URL. Only fitting accounts are enriched, and only with the fields the score reads:

• Headcount, industry and country from Clay.
• The tech stack from job posts, with Sumble.
• Funding stage and date from Crunchbase, for venture backed segments.
• Legal status from North Data.

The cheapest, most disqualifying field runs first, and every value carries its source and date. An empty field counts as missing, never as zero.

4Score and tier

• Score every account
• Size tiers and plan channels

Scoring in Clay adds visible points per criterion after the disqualifiers, so every score can be explained. Then comes the backtest: best customers should score clearly above bad fits, with the market sample in between. When the weights are off you change the rules, raise the version and rescore. Accounts are never edited by hand. Without a backtest the score stays a hypothesis until the first outreach shows reply and meeting rates per segment.

The GTM Lead then sizes the tiers from capacity: people times weekly hours, divided by the touches and the time each account needs. Tier 1 fills by score, then tier 2, the rest goes to tier 3, and overflow waits. Dream accounts are picked by hand from tier 1, each with a written reason, after a look in Sales Navigator. Every tier gets a channel plan per market:

• Dream accounts: manual multichannel work.
• Tier 1: calls and semi automated sequences.
• Tier 2: email and manual LinkedIn.
• Tier 3: low touch outreach.

5Hand it off

• Review and publish the map
• TAM map ready

Before anything reaches the CRM, the Reviewer checks the map:

• Random rows per tier and from the exclusions, with a reason for every disagreement.
• Tier sizes against capacity, and scores against the backtest.
• Rows that identify a person, such as sole traders, flagged as personal data.

Publishing to HubSpot looks every company up first, because HubSpot does not deduplicate companies created through its API. The exclusions are published too, with their reasons, so the next pull and Lead Sourcing skip them, and the map version gets a refresh date. The run closes when the GTM Lead approves the map version and tier 1 is ready for Lead Sourcing.

Compliance checks

The playbook carries checks for the EU, Germany, Austria, Switzerland, the UK and the US. Two examples:

• Under GDPR, data about companies is out of scope, while sole traders and names that identify a person are personal data.
• In Germany, advertising email needs prior express consent.

They are checks for your Privacy Lead and no legal advice.

Run it in Vanthis

In Vanthis the playbook becomes your own Motion on the Canvas. You adapt it to your tools and markets, and your agent, Claude or ChatGPT, works through it step by step with each step's instructions. To run it somewhere else, download it as Markdown or as an agent skill.