Apollo Icp Builder

---
name: apollo-icp-builder
description: "Turn a business and its ICP into a real Apollo search, a shared profile.yaml, and one to three custom scoring signals, validated on a sample. Use to define who to target on Apollo before building a list."
---

Read [runtime rules](../operator-context/references/runtime.md) once per conversation before this skill. **Without an authorized local terminal and authenticated Apollo CLI, use [connector-only instructions](connector-only.md) instead of the local procedures below.** For outbound work, load [Operator Context](../operator-context/SKILL.md) first, using its connector-only path when appropriate.

# Apollo ICP builder (targeting)

Turn a business into three things: a filled `client-profile.yaml`, a concrete Apollo search that returns the right people, and one to three custom scoring signals, all validated by a human on real samples before anyone builds a full list.

This is the front door. Nothing downstream is honest without it. A great sequence sent to the wrong list is a great sequence wasted.

## When to use

- Setting up outbound for a new business or campaign, with no `profile.yaml` yet.
- The ICP is vague ("B2B founders," "SMBs") and needs to become a real Apollo search.
- Re-targeting: the current list is not converting and you suspect the ICP, not the copy.

## Principle

Read `../operator-context/references/outbound-principles.md` if you have not. The two that drive this skill:
- **Scoring is custom, not a universal rubric.** Define one to three data points that actually separate good fit from bad for this client. Do not import a generic 100-point model.
- **Validate with samples.** Pull 50 to 100 real prospects and get a human "yes, this is my customer" before building the full list. Never skip this.

## Process

### 1. Anchor on the business
If `brief.md` exists, read it first (see `business-brief`, Context). It answers most of this step: what they sell, who buys, why, and the voice. Say back a one-paragraph summary and propose an ICP starting point drawn from its "Who buys" and Proof sections.

If there is no brief, offer to build one with `business-brief` (the better path). If the operator wants to move fast instead, do the lite version: read the website, say back in one paragraph what they sell, who to, and the value proposition, then propose an ICP starting point (titles, industries, size) drawn from their case studies and homepage. Ask for corrections. If there is no website either, get two sentences: what they sell and to whom.

### 2. Separate hard filters from soft preferences
For every criterion, ask: "If someone matches everything except this, do we still reach out?"
- **No** to hard filter (must match, goes in the search).
- **Yes** to soft preference (a personalization angle or a scoring signal, not a search filter).

Job title and industry are usually hard. Headcount is usually soft at the edges. Triggers (funded, hiring, tech installed) are almost never hard filters, they are signals.

### 3. Translate the ICP into Apollo filters
Map each hard criterion to a real Apollo field. Do not invent filters. The full field map with gotchas is in `references/apollo-search-reference.md`. The common ones:

- Titles to `person_titles` (set `include_similar_titles: false` for strict matches).
- Seniority to `person_seniorities` (`senior`, `manager`, `director`, `vp`, `c_suite`).
- Location to `person_locations`.
- Company size to `organization_num_employees_ranges` (e.g. `['51,200']`).
- Industry to `q_organization_keyword_tags` (e.g. `['SaaS']`) or NAICS/SIC codes.
- Revenue to `revenue_range` (raw integers, no symbols).
- Tech stack to `currently_using_any_of_technology_uids`.

### 4. Define one to three scoring signals
What separates a good-fit account from a barely-fit one for this business? Pick one to three. Two kinds:

- **Filter signals** map to a native Apollo field, so they narrow the search directly. Example: "has a real sales team" to `organization_department_or_subdepartment_counts: {master_sales: {min: 5}}`. "Recently funded" to `latest_funding_date_range` (company search).
- **Research signals** need a look at the company. Define the rule during targeting and apply it during list building. Browse the company site or, if discovery advertises `apollo_agent_find_prospects`, offer that option under the operator-choice, effect, cost, and approval rule.

Each lead ends up tagged **High, Medium, or Low** priority (that is all the user sees). If you have nothing to start from, begin with Apollo's built-in Bronze-to-Platinum fit score, then upgrade to your own one to three signals as the campaign teaches you what predicts fit. See `references/scoring-starter-frameworks.md`. Always frame scoring as custom, never as the one true rubric.

### 5. Pick the buying-committee personas
Decide who at the account you are reaching. Set `person_seniorities` and `person_titles` for each persona (champion, economic buyer, end user). Keep the list tight. How you *write* to executives vs managers (the ATL/BTL split) is Message, not here.

### 6. Build and sanity-check in Apollo
Run `apollo_mixed_people_api_search` with the filters, `per_page: 10`, `page: 1`, and read the total available count.
- Over 50,000: too broad (that is Apollo's display ceiling anyway). Tighten with more filters.
- A few hundred or fewer: too narrow. Loosen a soft edge, or widen titles/geo.
- A workable range: good. Note that search does not return emails and may mask last names; enrichment happens at List.

The count is the `total_entries` field in the response. **When it comes back huge, do not just say "tighten," find what is inflating it.** Broad title buckets ("manager", "events", "marketing") plus `include_similar_titles: true` can multiply the count 100x or more. Re-run once with `include_similar_titles: false` and only the strict core titles to see the real base, then widen on purpose. Report the difference to the user so they choose the breadth, for example: "679 people have a literal trade-show title; 91,000 if we widen to all marketing and events roles." One inflated number trusted blindly is how bad lists start.

If you use `apollo_mixed_companies_search`, it costs 1 credit per call that returns results. Confirm first with the exact words: "This will consume 1 credit. Do you want to proceed?"

### 6b. Size several angles before committing to one

An ICP is *who* to reach. An **angle** is *why they are relevant right now*, and the same ICP usually supports several. Because people search costs nothing, you can size half a dozen angles in a few minutes and choose on real numbers instead of instinct. Almost nobody does this, and it is one of the cheapest good decisions available.

Angles come in three kinds, and the difference decides how long a list stays good:

| Kind | Example | Decays? |
|---|---|---|
| **Timing signal** | Hiring an SDR right now, just raised, just changed jobs | **Yes.** Sharp while it lasts, stale within weeks. Rebuild it, do not stockpile it. |
| **Technographic fit** | Already uses the tool your offer wraps around | Slowly. Someone who owns the product qualifies themselves. |
| **Structural fact** | 11-200 employees with 0-2 people in sales, so the founder is selling | **No.** Permanent until the company changes shape. The most durable list you can build. |

Size each candidate with `per_page: 1` and read `total_entries`. A real session sized seven angles for free and the spread was large: one signal-based angle at 3,243, a technographic angle at 1,044, and a structural angle at 2,837, against an unfiltered baseline of 203,908. That baseline is worth computing every time, because it shows what choosing an angle is actually buying you.

Then pick deliberately, and **expect roughly 85% attrition** from raw count to sendable after drift cuts, deduping, verified-only filtering, and catch-all removal. A 1,000-person angle is a 150-person campaign.

**One angle per campaign.** Two angles in one campaign means one message trying to be relevant for two different reasons, and a result you cannot attribute to either. If you run several, keep them as separate lists and suppress each against the others (List, step 3).

Full treatment, including the three kinds of angle and how to sequence several: `references/angles.md`. Starting from a named set of companies instead of an ICP, or wanting several people per company: `account-based-outbound`.

### Apollo's skills and this toolkit

Apollo Operator complements Apollo's own tools. When Apollo's prospecting, enrichment, sequence loading, analytics, or GTM Strategist skill is available and fits the request, offer that skill first. Use its result as the input to the relevant Operator skill. Continue with deliverability, independent verification, list quality, suppression, copy review, and reporting as needed. Do not imply those optional skills are installed without checking.

**Read each action's effect.** Apollo AI actions advertised under `apollo_write` can spend credits or create records. Name a relevant discovered action, establish cost and balance, and wait for the operator's explicit approval before dispatch.

**Read each action's effect.** Apollo AI actions advertised under `apollo_write` can spend credits or create records. Name a relevant discovered action, establish cost and balance, and wait for the operator's explicit approval before dispatch.

**What comes back is a search, not a list.** The agent does not size the attrition between an audience and a sendable list, grade composition, or verify anything. So treat its output as the input to 6b (size it against the other angles), 7 (validate a sample), and then List, exactly as you would a filter set you wrote yourself. The full stance is in `operator-context`.

**Apollo's GTM Strategist skill is another option where installed.** Apollo's own Claude Code plugin ships `/apollo:gtm-strategist` (added 2026-09-16, read in full 2026-09-28), a user-invoked skill that turns a pipeline goal into one recommended play: diagnose before searching, reason from category to active responsibility to operational pressure, form a testable "why now" hypothesis, contrast it with the obvious approach only when a better one exists, build the audience from the hypothesis rather than from the filter menu, validate on a cohort of about 20 to 30 accounts, then draft and execute through Apollo's sibling skills with the tool's own approval gates. It labels its evidence as verified, inferred, or assumed, and it discloses cost per tool rather than assuming every call spends. That is good judgment and it runs on the same connector this library does, with no master key needed.

Where it ends is where this library starts. It says so itself: no product how-to, no data cleanup, no performance monitoring in its first version, and it hands off to sequence loading and activation. Nothing in it checks a domain's warmup age, verifies an address independently of Apollo's status, grades the NAICS mix of what the search returned, suppresses against last quarter's campaign, caps people per company, or knows that a sized audience of 7,000 becomes a sendable list of 1,000. So: if the operator wants the strategy formed by Apollo's strategist, say so as an option at steps 1 to 4 and let them choose. Its validation cohort maps onto step 7 here, at the account level instead of the person level. Its audience is then the raw list this library's List and Infrastructure phases take from there, and its draft goes through `sequence-reviewer` like any other copy. The two disagree on one thing worth knowing: the strategist treats "recently funded" as a clue to reason from, this library adds the measured trap that a third of a funded universe can be acquisitions, and both are right.

### 7. Validate with samples
Pull 50 to 100 people from the search. Put them in front of a human: "Is this your ideal customer?" Walk a few concrete examples, not just the count. Document every "avoid X" and "prioritize Y" as an exclusion or a soft preference. Do not proceed to the full list build until the samples pass.

### 8. Write the profile
Save the ICP, the scoring signals, and the exact Apollo filter set to `profile.yaml`. The filter set is the source of truth (the MCP cannot create a named Apollo saved search, so store the filters, and optionally recreate the saved search by hand in the Apollo UI).

```yaml
icp:
  titles: [...]
  seniority: [...]
  industries: [...]
  headcount: <range>
  geos: [...]
  exclusions: [...]
scoring_signals:
  - name: <e.g. sales team >= 5>
    type: filter | research
    apollo: <field, if a filter signal>
    rule: <how to decide, if a research signal>
apollo:
  people_search_filters: { <the exact param object you ran> }
```

## Output

A filled `profile.yaml` with a validated ICP, one to three scoring signals, and a reproducible Apollo filter set. Hand off to **List (list building)** to enrich, apply research signals, grade, and build the full list.

## Common mistakes

- Treating a trigger (funded, hiring) as a hard filter. It shrinks the list 20x and it is a signal, not a requirement.
- Building the full list before samples are approved.
- Importing a generic scoring rubric instead of finding the one to three signals that matter here.
- Titles too broad. "Manager" alone pulls every department. Pair titles with seniorities and departments.