HG Insights

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_search directly and needs to run FAI first.

Tools you'll touch

  • company_fai: department mix and decision-maker / influencer titles per product (see hg-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_titles such as "VP Sales Operations" and influencer_titles such as "Sales Operations Manager".
  • contact_search then asks for exactly those titles and returns the people who run the CRM. Engineering becomes a secondary list for integration plays.

The chain

  1. company_technographic: get the product_id.
  2. company_fai with product_ids, sort_field:"department_usage_share", then dedupe by department. Add has_decision_maker:true to pull decision-maker rows.
  3. Build one personTitles array from the deduped decision_maker_titles and influencer_titles of the target department, plus close variants ("VP Sales Operations", "Head of Sales Operations", "Director, Revenue Operations").
  4. contact_search once with that array.
  5. contact_enrich only for the contacts you will actually use.

contact_search rules

  • One call, all variants. Put every title variant in one personTitles array. 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 personTitles and/or personSeniorities (c_suite, vp, head, director, manager, ...). An unfiltered search on a big company returns an unranked default page.
  • Selector: prefer company_domain over company_name. Leave provider on "auto".
  • Output: contacts[] with name, title, seniority, linkedinUrl, city / state / country, and an id. No email or phone.

contact_enrich rules

  • Enrich only the contacts you chose, by contactId from contact_search (most accurate). Batch up to 25 via contacts.
  • Pass revealPhone:false unless 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 id or 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

  1. A generic title pattern. "VP of IT" matches every IT VP; without FAI you don't know which one runs the workload.
  2. Skipping FAI because "of course Sales runs the CRM". Plenty of companies run it from Customer Success or RevOps. One call settles it.
  3. One search per title, or retrying after 0 results. Each call costs 2 credits and the cap is two.
  4. Enriching with the default phone reveal. It costs 2.2 per contact for a phone that is usually absent.
  5. Inventing emails after contact_search. Names, titles and LinkedIn URLs are real outputs; emails are not. See stakeholder-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