Map competitive set for a target company.
Produce a defensible competitor map for any target in minutes, anchored in current public evidence.
Prompts used
The exact LLM prompts this automation calls — system instructions and user messages, in execution order, with the model each step uses.
- Competitor Profile Builder (per-row enrichment) →1 prompts
Per-competitor enrichment prompt that runs inside the Map Competitive Set automation. For each similar company returned by PitchBook, this prompt takes the structured facts the upstream steps already pulled (financing, investors, website) and asks the model to research the missing qualitative fields — tech approach, key use case, balanced pro / con — and return them in a strict delimiter-separated shape so the next code step can split the response into independently usable variables without LLM-aware parsing. Pairs 1:1 with the Map Competitive Set automation and the Competitor Finder module in the Diligence playbook; one invocation per row in the competitor table.
Helper code snippet
Reusable code that powers a step inside this automation — loop bodies, parsers, routers, and other glue.
- PitchBook Competitor Enrichment (loop helper) →Python · pitchbook_competitor_enrich.py
Per-competitor PitchBook enrichment used as the loop body of the Map Competitors automation — bio, most-recent financing, financials, and investor names for a single PB ID.
Reference build
One flow, end to end: an analyst drops a target into a list on the company record, and minutes later a fully enriched, opinion-bearing competitive landscape lands on the deal page — every row built from PitchBook fundamentals, web context, and a paired GPT pro/con.
Vendors below are our choices. The flow is roles-not-vendors; every layer swaps cleanly.
Contract — in and out
One input (an Attio company record). One output (a populated, linked competitor database on the target's deal page).
| Field | What it holds |
|---|---|
| trigger.record | Input — Attio company record added to the 'Find Key Competitors' list. Provides name + primary domain. |
| pbId (target) | PitchBook ID for the target, resolved via /search using domain first, name as fallback. |
| similars[] | Up to N peer companies returned by PitchBook's similar-companies endpoint, fanned out into a loop. |
| competitor.pbId | Per-row PitchBook ID for each similar — gates the enrichment call. Missing pbId → row filtered out. |
| competitor.facts | Per row: total raised, last round date, post-money valuation, key investors, website, status. |
| competitor.llm | Per row: tech approach, key use case, pro, con — generated by GPT against fact bundle + web. |
| notion.row | Output — one Notion database row per competitor, relation-linked back to the target company page. |
Gotchas
What you learn running this flow on a hundred targets.
- 01One flow, two halves: a CRM-triggered front end (Attio list entry) and a reusable enrichment back end. The back half is structured as a sub-zap so any other surface — a Notion button, a partner Slack command, a memo orchestrator — can call it with just a pbId and get the same rows back.
- 02Resolve to a PitchBook ID before anything else. Domain is the strongest signal; name is the fallback. Without a pbId the similars endpoint has nothing to anchor on, so the run exits early with a clean 'no pb id found' rather than guessing.
- 03Prefer COMPANY-typed results from /search. PitchBook's search index also returns funds, investors, and deals against the same string. Filtering to primaryFirmType=COMPANY before taking the first match is the difference between mapping competitors and mapping investors.
- 04Fan out, then filter. The similars list returns dozens of candidates; the loop runs enrichment in parallel and a filter step drops rows missing a pbId or below a raise / stage threshold so the LLM never burns tokens on noise.
- 05Two GPT calls per row, not one. First call summarizes tech approach and use case from PitchBook + web; second call writes a paired pro/con from the same context. Splitting the prompts keeps each one short, cheap, and easy to iterate.
- 06Notion write is upsert, not insert. The flow searches the target's existing 'Key Competitors' database first; if a row for that competitor already exists, it patches instead of duplicating. Re-running on the same target is safe.
- 07Relation-linked back to the target. Every row carries a Notion relation to the target company page, so the competitor set surfaces inline on the deal record — not just as a standalone database the team has to remember to open.
- 08Failures are logged at the row level. One bad pbId, one rate-limited enrichment call, one GPT timeout skips that row and continues. The run never aborts the whole landscape because one competitor's PitchBook page is malformed.
Swap matrix
Every layer is replaceable. The trigger → resolve → fan out → enrich → synthesize → upsert contract is what the flow depends on.