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

Tools you'll touch

  • company_fai — department-mix per installed product (see hg-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_search then 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 is 3 credits per call (pricing.ts).

Common pitfalls

  1. Calling contact_search with 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.
  2. 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.
  3. Inventing emails after contact_search. Names + titles + locations are real outputs; emails are not. See stakeholder-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