← All projects
OutboundDataAgents

TAM mapping

Our best customers are companies like freight auditors and medical billing firms that process paperwork on behalf of their clients. They never call themselves document companies, so they don't show up on vendor lists or in an industry filter, and every outbound list we built kept missing them.

Fall 2026·Python, SQLite, Claude, Serper, HubSpot
01Where I started

Learn the vocabulary from customers we already have

Instead of guessing at categories, I had agents read our existing customers' websites and pull out how they describe the work they do for their clients, and ignore how they describe themselves as a company. That gave me a few hundred categories to search, each one tied back to the kind of customer it came from.

derived_categories.json
{
  "key": "es_mga_wholesale_underwriting",
  "label": "E&S / Wholesale MGA Underwriting",
  "phrases": [
    "excess and surplus lines underwriting",
    "wholesale MGA",
    "binding authority MGA",
    "program underwriting for wholesale brokers"
  ],
  "why": "MGAs receive broker submission packets in inconsistent formats and must quote, underwrite and bind from them."
}
One of the categories, built from how a group of our insurance customers describe their own work.
02The idea

Search the way an operator writes

A software vendor writes "AI-powered claims automation." A claims administrator writes "we process claims on behalf of our carrier clients." So every category got searched in that second voice, with phrases like "we manage" and "on your behalf," which is what pulled in operators instead of vendors. When a category still flopped, it usually named the wrong side of the deal, like "HVAC financing" bringing back HVAC shops when what I wanted was the lenders behind them.

Search the way a vendor writes, then the way an operator writes
    Company names here are made up.
    03Judging

    Make the model show its work

    For every company, a model reads the site and decides whether documents run through the core of the business, and it has to name the documents and quote the page. The prompt is blunt about the trap: a good fit usually never mentions documents at all. I checked batches as they came in, and when a cheaper model started giving the same answer for everyone, I threw that batch out and moved the judging to a stronger model.

    judge_prompt_template.txt
    Apply an EXISTING tuned rubric to classify companies for a
    document-extraction seller.
    
    Key point: these are OPERATORS who never describe themselves as
    document companies. A site that never mentions documents is the
    EXPECTED state for a good fit and must NOT lower your verdict.
    Reason about the business mechanism, not page vocabulary.
    
    Judge EVERY company INDIVIDUALLY:
    {"domain": "...", "verdict": "...", "documents": [...],
     "who_sends_them": "...", "quote": "..."}
    04Putting it together

    One table sales will actually open

    Everything got merged with HubSpot and our old prospect lists, cleaned up and tiered, and then put into an explorer where you go industry, then sub-industry, then company, and see the evidence the model read off that company's own site.

    TAM explorer
    TAM explorer drilled into freight auditdocuments named from their own site
    The real explorer, drilled into freight audit. Company names and anything identifying are blurred.
    05What I didn't expect

    It showed us the documents we don't cover

    Since every qualified company has its documents listed, I could count which documents come up a lot that we don't have a config for yet. That list went straight to the product team.

    TAM explorer · Documents
    Documents across qualified companies with config coveragedo we ship a config for it?
    Where it is now

    It's the account list outbound works from, and the documents it turned up are part of how we decide what to build next.