HG Pain-Point Segmentation

Name and detect the shared situations that group a target list, and map each to the persona who owns the pain.

When to use

• After building a target account list, to group accounts by shared pain points.
• When the user provides pain points, to classify accounts against them.
• When the user doesn't provide pain points, to find candidate patterns in the data.

For the full procedure and scoring, use the Segment by Pain Point workflow.

Tools you'll touch

• get_product_category, get_vendor_information, product_search_and_enrich (action search): resolve categories, vendors and products to ids. Cost: free.
• search_companies: build or test a segment across many companies. Cost: 1 per 100 companies returned.
• company_technographic: confirm the pattern on known accounts (vendor counts, gaps). Cost: 2 per company.
• company_install_time_series: momentum per account. Cost: 3 per product row returned.
• company_spend: category share of IT spend. Cost: 3 per company.
• hg_data_query (optional, when available): list-level SQL. Cost depends on data scanned.

Resolve every name to an id first. Invalid ids aren't rejected; they match nothing and return 0.

Naming convention

Segments are always prospect-centric: named by the prospect's situation, never the seller's motion.

Good (Prospect-Centric)	Bad (Seller-Centric)
"The multi-vendor service desk with rising ticket complexity"	"ITSM Displacement"
"The 5+ monitoring stack with no correlated alerting"	"Cross-sell opportunity"
"The mainframe estate running batch without CI/CD"	"Competitive win-back"
"HR platform transition window"	"Competitor churn target"
"Two data platforms running side by side"	"Protect and expand"
"Another platform carries the main workload"	"Net new"

Name the situation even when it involves your own product. Accounts that fit no segment are listed apart as "not grouped", each with the reason (no signal, no data). That list is not a segment and gets no name.

Detection patterns from data

Use search_companies and company_technographic first. SQL is optional, for orgs that have hg_data_query (see hg-data-query-discipline).

search_companies rules that apply to every pattern: pair at least two filter groups (installs plus firmographics, for example); set firmographics.company_level (CORPORATE_PARENT or GLOBAL_HEADQUARTER) so lists don't fill with subsidiaries and sites of the same family; output is identity only (hg_id, name, domain), so enrich survivors with batch tools; limit max 100, paginate with offset.

1. Category sprawl

Signal: too many vendors in one category.
Detect:

• Pool: search_companies with installs.product_categories: { ids: ["<category id>"], inclusion_method: "ANY_PRESENT" } plus a firmographic filter.
• Count: company_technographic on the pool (up to 25 per call) with category_ids:["<category id>"]; count distinct vendor_id per company. Dedupe on product_id if you passed country_codes.
• SQL option: GROUP BY url_id HAVING count(DISTINCT vendor_id) >= N on the resolved category.

Severity: severe 5+ vendors; moderate 3 to 4; mild 2 (dual-stack).
Persona: VP of IT Ops, SRE Lead, Director of Engineering.

2. Capability gap (has X but not Y)

Signal: the company has one capability but lacks the natural complement.
Detect:

{
  "installs": {
    "product_categories": { "ids": ["<category X id>"], "inclusion_method": "ANY_PRESENT" },
    "products": [ { "ids": [<leading Y product ids>], "inclusion_method": "NONE_PRESENT" } ]
  },
  "firmographics": { "company_level": "CORPORATE_PARENT" }
}

NONE_PRESENT proves only that the listed products are absent. Confirm on survivors with company_technographic and category_ids for Y: a non-empty company_id with empty installs means none detected.
SQL option: CTE for "has X" + NOT IN for "has Y".

Examples:

• Has ITSM but no ITOM: "Ops visibility gap".
• Has cloud infrastructure but no FinOps: "Cloud spend without governance".
• Has CRM but no marketing automation: "Pipeline without top-of-funnel".

Persona: depends on the gap: IT Ops for ITOM, Finance or VP Infrastructure for FinOps, CMO for marketing automation.

3. Declining momentum

Signal: negative intensity_momentum on a product.
Detect: search_companies has no momentum filter. Build the pool with installs.products (ANY_PRESENT), then call company_install_time_series per account with product_ids. -20 or below = declining; -10 to -20 = early decline. Drop the current month and any partly loaded last month before reading the series.
SQL option: join install_intensity_momentum_global with intensity_momentum <= -20 (see hg-momentum-signals).

Examples:

• Declining usage of an incumbent HR platform: "HR platform transition window".
• Declining on-prem storage: "Storage modernization underway".

Persona: CIO, VP Digital Transformation, VP Infrastructure.

4. Over-investment

Signal: a category takes a disproportionate share of IT spend relative to peers.
Detect: company_spend (batch up to 25). Divide the category row by the "Total IT" row for the same country scope; compare with a peer batch from the same industry and size band. Pool option: search_companies spend[] with a category id and a USD range.
Example: security spend well above peers: "Security-heavy, looking for consolidation".
Persona: CISO, CFO, VP Security.

5. Under-investment

Signal: category spend below peers for company size and industry.
Detect: as pattern 4. Low spend can mean outsourced services or spend embedded in cloud fees; check the stack before calling it a gap.
Examples:

• Security share well below peers in critical infrastructure: "Security spend gap".
• Low cloud share in a digital-native industry: "Cloud adoption laggard".

Persona: CISO (security), CIO (cloud), Board or Audit Committee (compliance).

Spend is a modeled estimate, not invoices. Never state a typical, normal or usual share for a category, not even as a range. Judge a share only against a peer batch (same industry and size band). Without one, say the share can't be judged yet and offer the peer comparison with its cost. A threshold the user gives you is theirs; label it so.

Required content

Layout is up to the formatting skills. For each segment, the answer contains:

• A name describing the prospect's situation (naming rules above).
• The accounts in it.
• The data signal behind it, with its source tool (for example "4 vendors in the category [company_technographic]").
• The persona who owns the pain (a title), per segment.

Plus the "not grouped" accounts with their reasons.

Segment-to-persona mapping

Detected Pattern	Suggested Persona
Category sprawl in IT ops	VP IT Operations, SRE Lead
Security spend gap	CISO, VP Security
Legacy ERP / declining platform	CIO, VP Digital Transformation
Multi-cloud without orchestration	VP Infrastructure, Cloud Architect
HR tech transition	CHRO, VP People Ops
Data / analytics fragmentation	CDO, VP Data Engineering
Observability sprawl	VP Engineering, SRE Lead

Common pitfalls

1. Seller-centric segment names. Rename by the prospect's situation.
2. Guessed category or product ids. They match nothing and look like "no segment".
3. Reading NONE_PRESENT as "no capability". It covers only the products listed.
4. Mixing family members in one list. Set company_level.
5. Comparing install intensity across companies. It is unbounded; rank within a company only.
6. Presenting spend thresholds as benchmarks. Compare with peers and label spend as modeled.

Reference

• V2 tool docs: https://phoenix.hginsights.com/docs/mcp-tools/v2/search-companies
• V2 tool docs: https://phoenix.hginsights.com/docs/mcp-tools/v2/company-technographic
• V2 tool docs: https://phoenix.hginsights.com/docs/mcp-tools/v2/company-spend
• Full docs for LLMs: https://phoenix.hginsights.com/docs/llms-full.txt
• Related skills: hg-mcp-calling-rules, hg-search-companies, hg-technographic, hg-momentum-signals, hg-spend, hg-data-query-discipline