Skill: FAI before Contact Search
Stakeholder lists targeted at the team that runs the tool — not the most senior IT title.
Overview
Stop your stakeholder lists from defaulting to 'VP of IT' for every account. Claude learns to identify the operating department first (via FAI), then search for named humans inside that department — so a CRM workflow targets a Sales VP, a data warehouse workflow targets a Data Engineering lead, and the generic IT title is the exception, not the default.
Use cases
Discovery calls with the right title in the room
FAI surfaces that the CRM is operated by Sales Ops; the stakeholder list lands on the VP Sales Ops + the Director of CRM Operations. Your AE walks in with two named, in-role contacts instead of a generic shortlist.
Multi-thread plays with the secondary buyer surfaced
Same workflow finds Engineering 8% as a secondary signal and includes the integrations lead as a parallel touchpoint. The deal multi-threads naturally — no manual research session to find the integration buyer.
View full skill
FAI before Contact Search
When to use
- A workflow is building a stakeholder list for an outbound or research deliverable.
- A prompt is about to call
contact_searchdirectly and needs to be told to run FAI first.
Tools you'll touch
company_fai— department-mix per installed product (seehg-fai)contact_search— named-contact search by company + title pattern
The composition rule
FAI before contact_search. Always.
contact_search is keyword-based: it takes a title pattern ("VP Sales", "Director of Engineering") and a company, and returns named individuals matching the pattern. It is not aware of which department actually operates the workload your workflow cares about.
Without FAI:
- The workflow asks for "VP of Operations at Siemens" → returns a senior Operations title that may have nothing to do with the CRM workflow you wanted to discuss.
- The workflow asks for "Sales leadership at Siemens" → returns regional sales VPs across geographies, not the function that runs the SFDC instance.
With FAI:
- FAI returns "Salesforce CRM at Siemens, Sales 58% / Engineering 8%" → the workflow now knows the operational center of gravity is the Sales org, with a small Engineering touchpoint.
contact_searchthen targets "VP Sales Operations at Siemens" → returns the title that actually runs the CRM. The Engineering 8% becomes a secondary list for integration plays.
What HG actually returns from contact_search
Per mcp-apollo.md, contact_search provides named-contact lookups: full name, title, location, LinkedIn URL when available. It does not provide email or phone — those come from contact_enrich, a separate, higher-cost call.
The Phoenix-side credit cost for contact_search is 2 credits per call; contact_enrich bills 0.2 credits per revealed email plus 2 per revealed phone, and phone reveal is opt-in (revealPhone, default false) (pricing.ts).
Common pitfalls
- Calling
contact_searchwith a generic title pattern. "VP of IT" matches every IT VP at the company; without FAI you don't know which one runs the workload. - Skipping FAI because "the workflow is just CRM, of course Sales runs it". Plenty of companies run their CRM out of Customer Success or RevOps. FAI takes one call to verify.
- Inventing emails after
contact_search. Names + titles + locations are real outputs; emails are not. Seestakeholder-card-discipline.
Citation rules
When this composition drives a stakeholder pick in the deliverable, cite both inputs: "FAI: Sales 58% / Engineering 8% (HG, May 2026); contact_search: 3 candidates returned, top match J. Doe, VP Sales Operations".
Reference
hg-insights-api.md#functional-area-intelligence— FAI semanticshg-fai— what FAI returns and how to read itmcp-apollo.md—contact_search/contact_enrichsemanticshg-tool-chain-account-research— the broader chain