The questionnaire is an intake document, not executable targeting
A client says they want operations leaders at growing US companies. An operator opens Apollo, selects Operations, Director, United States, and 51 to 500 employees, then exports thousands of people. The search looks tidy. The logic is still missing.
Which operations roles count? Does the buyer work at headquarters or a regional business unit? Is geography based on the person or the employer? Does "growing" mean hiring, funding, headcount, revenue, or a recent operational change? Which industries are forbidden? What happens when the preferred title is absent?
Those questions are why an ICP questionnaire should be treated as source material for a small compiler. Codex or Claude Code can turn narrative answers into a structured rule file, validate it against provider documentation, and generate a human-readable search brief. The agent should not silently decide the ICP.
Start with five rule types
- Hard include: a lead cannot pass without it.
- Hard exclude: a lead must be rejected when it is present.
- Preferred signal: raises priority but does not determine eligibility alone.
- Fallback: an approved alternative when the primary role or signal is unavailable.
- Unknown: a question the client has not answered, so the system must not invent a value.
This distinction prevents a common failure: turning preferences into mandatory filters until the search returns almost nothing, or turning exclusions into vague scoring hints until bad-fit accounts enter the list.
Map business meaning to provider meaning
Apollo's current People API Search separates personal location from organization headquarters location. It also documents title, seniority, employee range, revenue, technology, active job posting, domain, and email-status filters. Title matching can include similar titles unless include_similar_titles is set to false. That single default can materially change a list.
The endpoint returns net-new prospect records but does not return email addresses or phone numbers. Apollo directs users to separate enrichment endpoints for that data. It also documents a 50,000-record display limit, so broad searches need to be partitioned into stable, non-overlapping slices.
{
"must": {
"organization_locations": ["United States"],
"organization_num_employees_ranges": ["51,200", "201,500"],
"person_seniorities": ["director", "vp", "head"]
},
"titles": {
"primary": ["Head of Operations", "VP Operations"],
"fallback": ["COO", "Director of Operations"],
"include_similar_titles": false
},
"exclude": {
"industries": ["Staffing and Recruiting"],
"domains": ["existing-customer.example"]
},
"unknowns": ["minimum revenue", "required growth signal"]
}The field names above illustrate a contract, not a universal Apollo payload. Your compiler should compare every key and accepted value with the current provider documentation before a live request.
Use a two-pass agent workflow
Pass 1: compile and challenge
Give the agent the completed questionnaire, the current provider schema, and a fixed output schema. Ask it to extract each statement, classify the rule type, propose the provider field, and list ambiguities. Require source quotations from the questionnaire so the operator can see where every rule came from.
Pass 2: test the search
Run a small preview, not a full export. Review a balanced sample of clear passes, edge cases, and apparent rejects. Ask four questions: did the filter behave as intended, did similar-title matching broaden the set, did location use the correct entity, and are exclusions deterministic?
Only then lock the search version. Store the questionnaire version, rule-file hash, provider payload, timestamp, result count, and sample audit. If the client changes one answer, create a new version instead of rewriting history.
A real operating lesson from a 39-question intake
In Ink Persuasion's internal operations, a client intake was built with four recommended buyer avatars and 39 fillable questions. The important control was not the number of questions. It was the rule that the questionnaire remained intake and confirmation, not launch approval. No lead list was created until the buyer avatars and exclusions were confirmed.
This is an anonymized operating observation, not a performance case study. It shows the governance point: a polished questionnaire can still contain unresolved contradictions. The compiler should expose those contradictions before a database turns them into thousands of rows.
Where this fits in a Clay replacement
The Clay replacement architecture explains the orchestrator, worker, and QA pattern. The ICP compiler sits before that system. It gives workers a stable contract and gives QA an answer key. After approval, pass that contract into the waterfall email enrichment system and preserve every selected value in a single source of truth for lead lists. Pair it with the sales agent runbook so role fallbacks, approval gates, and disqualifiers remain visible after enrichment begins.
Launch gate: do not export the full search until every hard rule has a source, every provider field has been validated, every unknown is visible, and a human has reviewed edge cases.
FAQ
How do you use AI filters in Apollo.io?
Translate the ICP into explicit company, role, geography, seniority, and exclusion rules first. Codex can draft that mapping and an Apollo payload, but an operator should review the proposed values and preview the results before exporting or enriching records.
How should you save Apollo.io filters?
Save the approved search in Apollo and keep the same rule set in a versioned text or JSON file. Record the ICP version, filter values, exclusions, fallback rules, and approval date so the search can be audited and rebuilt.
Can Codex create Apollo filters from a Google Doc?
Yes. It can extract the completed answers, normalize them into a rule schema, and produce a proposed Apollo payload. A human should approve the mapping before any paid enrichment or list export.
Should titles or seniorities drive the search?
Usually both. Titles express function while seniorities express level. Test the combinations because similar-title behavior can broaden results.
What if the ICP is still incomplete?
Keep unresolved fields as unknowns, run a small exploratory preview if appropriate, and return the evidence to the client. Do not disguise missing decisions as model confidence.
