Skill: FAI before Contact Search
Stakeholder lists aimed at the team that runs the tool, in one contact search instead of ten.
Overview
Stop stakeholder lists from defaulting to 'VP of IT' for every account. Claude runs FAI first to find the department that operates the product and the decision-maker and influencer titles it reports, then searches for those exact titles in one call, and enriches only the contacts you will use, with the phone reveal off.
Use cases
Discovery calls with the right title in the room
FAI shows the CRM is run by Sales Operations, with titles like 'VP Sales Operations'. Claude searches for exactly those titles and variants, so your AE walks in with names from the team that runs the workload.
Contact spend kept to what you'll use
All title variants go into one search, a zero-result search isn't retried, and only chosen contacts are enriched with the phone reveal off. The list costs a few credits instead of dozens.
Multi-threading with the secondary function
A smaller department share, such as Engineering on a CRM, becomes a secondary list for integration plays, so the deal multi-threads without manual research.
View full skill
FAI before Contact Search
Run FAI first so that contact_search targets the function that actually operates the workload.
When to use
- A workflow is building a stakeholder list for outbound or a research deliverable.
- A prompt is about to call
contact_searchdirectly and needs to run FAI first.
Tools you'll touch
company_fai: department mix and decision-maker / influencer titles per product (seehg-fai). Cost: 2 credits per call.contact_search: named people at a company by title, seniority and location. Cost: 2 credits per call, whatever the result count.contact_enrich: email (and phone, if asked) for chosen contacts. Cost: 0.2 per email reveal + 2 per phone reveal, per matched contact.
The composition rule
FAI before contact_search. Always.
contact_search matches titles. It doesn't know which department runs the product you care about.
Without FAI:
- "VP of Operations at Acme" returns a senior Operations title that may have nothing to do with the CRM workload.
- "Sales leadership at Acme" returns regional sales VPs, not the team that runs the CRM instance.
With FAI:
- FAI shows the CRM at Sales 58% / Engineering 8%, with
decision_maker_titlessuch as "VP Sales Operations" andinfluencer_titlessuch as "Sales Operations Manager". contact_searchthen asks for exactly those titles and returns the people who run the CRM. Engineering becomes a secondary list for integration plays.
The chain
company_technographic: get theproduct_id.company_faiwithproduct_ids,sort_field:"department_usage_share", then dedupe by department. Addhas_decision_maker:trueto pull decision-maker rows.- Build one
personTitlesarray from the dedupeddecision_maker_titlesandinfluencer_titlesof the target department, plus close variants ("VP Sales Operations", "Head of Sales Operations", "Director, Revenue Operations"). contact_searchonce with that array.contact_enrichonly for the contacts you will actually use.
contact_search rules
- One call, all variants. Put every title variant in one
personTitlesarray. Never one call per title. - Max 2 searches per request. The second is for a deliberate change (for example adding
personSeniorities), not a retry. - Stop on 0 results. Report "no matches found"; don't loosen and retry.
- Only six filters exist:
personTitles,personSeniorities,personLocations,organizationLocations,organizationNumEmployeesRanges,contactEmailStatus. There is no keyword parameter; express intent through titles and seniorities. - Large accounts: always pass
personTitlesand/orpersonSeniorities(c_suite,vp,head,director,manager, ...). An unfiltered search on a big company returns an unranked default page. - Selector: prefer
company_domainovercompany_name. Leaveprovideron"auto". - Output:
contacts[]withname,title,seniority,linkedinUrl,city/state/country, and anid. No email or phone.
contact_enrich rules
- Enrich only the contacts you chose, by
contactIdfromcontact_search(most accurate). Batch up to 25 viacontacts. - Pass
revealPhone:falseunless a phone is required. It defaults to true. Phone reveal often returns only a main line, and the phone fee applies per matched contact even if no number comes back. - A contact counts as a match only when the provider returns a verified email, a title or a phone. Unmatched contacts cost 0 and are dropped from bulk results, so match results by
idor name, never by array position. - Don't re-enrich a contact already in context.
Provenance
Contact data comes from a third-party provider, not HG; cite it as such. Contact results are cached for 7 days, and the provider refreshes its data on its own schedule.
Common pitfalls
- A generic title pattern. "VP of IT" matches every IT VP; without FAI you don't know which one runs the workload.
- Skipping FAI because "of course Sales runs the CRM". Plenty of companies run it from Customer Success or RevOps. One call settles it.
- One search per title, or retrying after 0 results. Each call costs 2 credits and the cap is two.
- Enriching with the default phone reveal. It costs 2.2 per contact for a phone that is usually absent.
- Inventing emails after
contact_search. Names, titles and LinkedIn URLs are real outputs; emails are not. Seestakeholder-card-discipline.
Citation rules
Cite both inputs and attribute contacts correctly: "FAI: Sales 58% / Engineering 8% of CRM usage (HG, Sep 2026); contacts: 3 candidates from third-party contact data, top match J. Doe, VP Sales Operations".
Reference
- V2 tool docs: https://phoenix.hginsights.com/docs/mcp-tools/v2/company-fai
- V2 tool docs: https://phoenix.hginsights.com/docs/mcp-tools/v2/contact-search
- V2 tool docs: https://phoenix.hginsights.com/docs/mcp-tools/v2/contact-enrich
- Full docs for LLMs: https://phoenix.hginsights.com/docs/llms-full.txt
- Related skills:
hg-mcp-calling-rules,hg-fai,stakeholder-card-discipline,hg-tool-chain-account-research