Skip to Content
CoursesTAM Sourcing03 Source companies at scale

Source Companies at Scale

Outcome: the matching account universe in one table, deduped on domain, with coverage checked against slices rather than assumed from one search.

Surface
App and MCP server
Level
Intermediate
Uses
find_companies
Credits
~20 for a 2,000-company universe
Prerequisite
Lesson 02's counted definition

One search is rarely the whole market

Every search endpoint has a result cap. A query that matches 12,000 companies returns the cap, not 12,000 — and nothing tells you which ones you got.

The fix is slicing: run several narrower searches whose union is your definition, and dedupe the results.


How to slice

Pick the dimension that divides your market most evenly.

Slice byGood whenWatch out for
CountryMulti-country marketsSlice sizes vary enormously; big countries may need further splitting
Employee bandBroad size rangesBand boundaries must not overlap or you double-count
Industry sub-categoryBroad industry definitionsCompanies tagged in two categories appear twice
Founded-year bandAge matters to your ICPMissing founded dates fall through every slice

Whichever you choose, the slices must be exhaustive — every company in your definition falls into exactly one — plus a catch-all slice for rows with the slicing field missing.

The missing-value slice is the one people forget, and it is where a systematic gap hides. If you slice by employee band and some companies have no headcount recorded, those companies are in none of your slices and vanish silently from the universe. Always add a slice for “field is empty”.


Detecting a cap

Compare count to returned rows

If a slice’s count said 5,000 and you got exactly 1,000, you hit a cap.

Look for round numbers

Exactly 500, 1,000 or 2,000 rows is almost never a real market size.

Split and re-run

Halve the slice on another dimension and confirm the two halves sum to more than the capped figure.


Dedupe across slices

Slices overlap in practice, even when they should not. Deduplication is on normalized root domain — lowercase, no protocol, no www., no path.

Two special cases to decide before you start:

  • Subsidiaries. uk.acme.com and acme.com — one account or two? Decide by how you sell and write it down.
  • Missing domains. A company with no domain cannot be deduped and cannot be enriched. Either resolve the domain or drop the row; do not leave it in.

Validate before enriching

The sourcing run is cheap; everything after it is not. Three checks, twenty minutes, before you spend anything downstream.

Read 25 random rows

Would you sell to these? More than a fifth wrong means the filters are wrong.

Check for known companies

Pick ten companies you know should be in the universe. Are they? Absences point to a filter that is too tight or a coverage gap.

Check the domain column

Sort by domain. Look for blanks, paths, duplicates that escaped normalization, and parent-company domains where you wanted operating entities.


Do this now

Choose the slicing dimension

Plus a slice for missing values.

Run each slice, recording count and rows returned

Any mismatch means a cap.

Split capped slices further

Until returned rows match the count.

Import all slices into one table

With dedupe on normalized domain enabled.

Compare total unique rows against your lesson 02 estimate

A large gap means either a cap you missed or an overlap you did not expect.

Run the three validation checks

Fix the definition before moving on.


Check your work

  • Slices are exhaustive, including one for missing values
  • No slice returned exactly its cap
  • Every row has a normalized domain
  • Unique row count is close to your lesson 02 estimate
  • You read 25 rows and checked for ten known companies

Where this breaks

Assuming one search covered the market is the failure that shapes everything downstream and is invisible in the output. The table looks complete, the enrichment runs cleanly, and the campaign performs — against a systematically skewed slice of your market, usually the largest and best-known companies. Always slice, and always check returned rows against the count.


Further automation

Save each slice’s filters. The monthly refresh in lesson 08 re-runs the same slices and appends only new matches — which, with dedupe on domain, is safe by default and turns the universe into a living dataset rather than a quarterly project.


Next lesson

04 — Layer firmographic filters, cutting the universe down to genuinely addressable accounts.

Reference for this lesson: find_companies, Import, Company, Tables.