HG Functional Area Intelligence

Use FAI to find which function operates a product at an account, and so who to target.

When to use

• A workflow needs to know which department actually runs a product, not which one signed for it.
• A prompt is picking a stakeholder: FAI tells you whether to target the operational lead or the budget owner.
• An author is about to claim "their CRM is owned by Sales" without checking. FAI confirms or refutes.

Tools you'll touch

• company_technographic: get the product_id (and vendor_id) for the product at this company. Cost: 2 per company.
• list_fai_departments: resolve department and role names to hex ids. Cost: free (10 rows by default; pass limit).
• company_fai: department, role and location usage for one company. Cost: 2 credits per call.

The call

1. Pass exactly one selector: company_domain or hg_id. Passing both is rejected.
2. Pass product_ids from company_technographic (max 20). There is no product-name filter. Without it, rows mix every product the company runs.
3. Either sort or filter by department, not both:
   • sort_field:"department_usage_share" (default sort_direction DESC) to see the mix, or
   • department_ids from list_fai_departments to read one function.
     department_ids and sort_field are mutually exclusive.
4. The default is 50 unsorted rows of a larger set (total_count). Sort, or raise limit (max 1000), before reading the mix.
5. Optional: country (ISO-2 codes), has_decision_maker:true, has_influencer:true, last_verified_date (keeps rows with last_verified_at on or after the date), role_ids from a prior response.

{
  "company_domain": "acme.com",
  "product_ids": [12345],
  "sort_field": "department_usage_share",
  "limit": 200
}

What comes back

One row per department × role × location for each product. Key fields: department_name, department_usage_share, department_signal_strength, role_name, role_usage_share, has_decision_maker, decision_maker_titles, has_influencer, influencer_titles, country_name / state_name / city_name, first_verified_at, last_verified_at, product_id, product_name.

How to read it

Dedupe first. department_usage_share repeats on every role and location row of that department. Group by product_id, then keep one value per department_id. Summing raw rows inflates every share.

department_usage_share is the product's usage mix across departments, in percent. Across departments it sums to about 100. role_usage_share is the role mix within that department. Read department_signal_strength as relative confidence within the result, not as a percentage.

Dominant department (over 50%): operational buyer. That's where the daily users sit. Their VP or Director is the discovery-call target.

Plurality (30 to 50%) with a clear runner-up: split decision. Common when Customer Success and Sales co-own a CRM. Plan for two stakeholders.

No department over 25%: distributed deployment. Typical of horizontal tools. Treat it as a company-wide rollout and target the IT or platform owner.

Low-share departments are reach signals. Engineering at 8% on a CRM is not the buyer, but it is a real touchpoint for an integration play.

FAI overrides org-chart inference. If the company has a CIO and FAI shows the CRM at 58% Sales, the CIO is not the operational buyer for that workload. Lead with the Sales VP and optionally copy the CIO.

Recency. Check last_verified_at. Rows not verified in the last 12 months describe a past footprint; filter with last_verified_date when you only want current usage.

Decision makers and influencers

Rows with has_decision_maker:true carry decision_maker_titles; rows with has_influencer:true carry influencer_titles. Call with has_decision_maker:true (and product_ids) to list them directly. Use these titles to build personTitles for contact_search (see hg-fai-vs-contact-search). FAI returns titles, never named people.

Operational buyer vs budget owner

FAI measures who uses the product, not who pays for it.

• Operational buyer: leadership of the dominant department. They run the workflow daily.
• Budget owner: usually one level up (the SVP or COO above a Sales-run CRM), or the decision_maker_titles FAI reports for the product.
  Keep the two groups separate in the deliverable (see stakeholder-card-discipline).

Common pitfalls

1. Reading the first 50 rows as the mix. They are unsorted. Sort by department_usage_share or raise limit, then dedupe by department.
2. Skipping product_ids. The rows then blend every product and the mix means nothing.
3. Combining department_ids with sort_field. Pick one.
4. Equating FAI with budget ownership. A 58% Sales share means the Sales VP runs it; someone above often signs.
5. Expecting the C-suite at the top. FAI is mass of usage, not seniority.
6. Treating FAI as a trend. It is point-in-time; there is no delta series.
7. Reading an empty result as "no usage". An unresolved domain and filters that matched nothing look the same. Check the selector and filters before concluding.

Citation rules

When FAI drives a stakeholder choice, cite the deduped shares and the date: "FAI: Sales 58% / Engineering 8% of product usage (HG, Sep 2026)". The percentages are part of the claim.

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/list-fai-departments
• Full docs for LLMs: https://phoenix.hginsights.com/docs/llms-full.txt
• Related skills: hg-mcp-calling-rules, hg-fai-vs-contact-search, stakeholder-card-discipline, hg-technographic