$ man clay-wiki/tam-list-building

TAM list building is the process of mapping your entire total addressable market in Clay. Not a "target account list" of 200 companies. The full universe. Every company that could theoretically be a customer. Then you filter, score, and tier that universe down to a prioritized list. This is a practitioner core play — it's the foundation that every other workflow builds on. If your TAM is wrong, everything downstream is wrong.

PATTERN

TAM building follows the write-to-table pattern. This is fundamental Clay architecture: 1. Source contacts from LinkedIn Sales Navigator, Apollo, ZoomInfo, or industry databases 2. Write them to a new table for accounts — the account table 3. Deduplicate by domain (one row per company) 4. Use the account table as your research table 5. Enrich and score at the account level 6. Source contacts from qualified accounts into a separate contact table The key insight: you source contacts, but you build accounts. Contacts are the input. Accounts are the unit of analysis. The write-to-table pattern converts a messy list of people into a clean list of companies.

PATTERN

Different TAMs require different sources: • LinkedIn Sales Navigator — best for company search by revenue, industry, geography, employee count. The standard starting point. • Apollo / ZoomInfo — firmographic filters at scale. Good for export and import into Clay. • Industry databases — NRF member lists, franchise directories, SEC filings for public companies. High signal for niche TAMs. • Apify — job scraping (Indeed, LinkedIn), Instagram scraping, Yelp scraping for SMB TAMs. When you need data that no enrichment provider has, scrape it. • Clay enrichment — batch processing to fill gaps. Use after initial sourcing to add tech stack, revenue, employee count. The biggest mistake: relying on one source. Every provider has blind spots. Cross-reference at least two sources for any TAM over 1,000 accounts.

PRO TIP

Clay is orchestration, not storage. If your TAM is 50K+ accounts, don't try to keep everything in Clay tables. Connect Supabase or Postgres as your storage layer. Clay enriches and scores. Supabase stores. The workflow: 1. Source raw accounts into Clay (in batches of 1,000-5,000) 2. Enrich and score in Clay 3. Write enriched records to Supabase via HTTP column or native integration 4. Clear the Clay table, load next batch 5. Query Supabase for the full enriched TAM This approach keeps your Clay table fast, avoids row limits, and gives you SQL-level querying over your entire TAM.

PATTERN

Building a TAM is not one step. It's four phases: Phase 1: Universe Build — source every possible company from every available database. Cast the widest net. Don't filter yet. Phase 2: Validation — run your primary gate against the full universe. For an IT services company, it might be "100+ physical locations." For an Atlassian partner, it might be "confirmed Atlassian footprint." The primary gate eliminates 60-80% of the universe. Phase 3: Enrichment and Scoring — for validated accounts, add firmographic depth, check intent signals, map competitive landscape. Score by signal density, not just firmographics. Phase 4: TAL Build — segment the validated TAM into Target Account List tiers. Tier A = high-intent signals + primary gate. Tier B = primary gate, no active signals. Tier C = qualified but lower priority.

PRO TIP

When standard enrichment providers don't cover your vertical, use Apify. Job scraping from Indeed and LinkedIn tells you which companies are hiring for specific roles (SDRs, engineers, franchise operators). Instagram scraping surfaces SMBs that don't appear in enterprise databases. Yelp scraping maps local businesses by category and review count. Apify isn't a default tool. It's the tool you reach for when Apollo and ZoomInfo return thin results. For SMB TAMs especially, Apify is often the only way to build a complete universe.

ANTI-PATTERN

If you source from multiple databases (Apollo + ZoomInfo + LinkedIn), you will have duplicates. Guaranteed. The same company appears as "Acme Inc" in one source and "Acme, Inc." in another and "ACME" in a third. Before any enrichment runs, deduplicate your account table by domain. Domain is the universal join key. Not company name. Company names are messy. Domains are unique. Dedupe by domain, keep the richest record, merge any extra data points from duplicates into the primary row. Then enrich. Enriching before deduplication wastes credits on records you're going to merge or delete.