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. Example: "has a pricing page," "sells a specific product line." Apollo's own AI research lives inside its agent (apollo_agent_find_prospects escalates to it, and apollo_agent_research_and_analyze runs it as a column on contacts you already have), reachable on the ordinary connector since 2026-11-08 and quoted in credits before it runs. Claude can also do it natively: read the site, decide, tag the record. Offer both and let the operator pick. This runs at list time (List), but define the rule here.

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:

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.

6c. Apollo's agent covers this step too. Say so.

Apollo ships its own targeting judgment on the MCP: apollo_agent_find_prospects turns a plain-language description into a search and escalates to semantic and AI research, apollo_agent_plan_gtm_campaign proposes campaign concepts from the Context Center and sizes each audience live, and apollo_agent_research_and_analyze can qualify existing records against a rule you write. Tested 2026-09-16: planning read the account's real product profiles, sized four audiences, stopped for confirmation, and cost nothing.

Offer it, do not decide silently. When the Context Center is already filled in and the operator wants a fast first cut, Apollo's agent is a legitimate route to steps 3 to 6 and the operator should hear that before you build filters by hand. It is reachable on the ordinary connector since 2026-11-08 (it ran only on v1 with a master key in September), so this is now a real choice, not a footnote. Check the live tool list rather than trusting this paragraph.

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 the other overlap. 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).

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.