Use Phoenix by HG Insights with AI

Phoenix is a source of company intelligence: firmographic, technographic, spend, intent, operating signals, contracts and government records, plus contact enrichment and web search. Every lookup starts from a company or person identity. A wrong identity silently poisons every later number, so settle identity before you pull data.

1. Confirm the target and the scope first

Before any lookup, pin down:

• Which company. Use company_search when the user gives a name. Names collide (subsidiaries, similar brands, the same name in different countries), so show the top candidates with whatever distinguishing detail the result gives and ask the user to confirm. Do not pick the first hit.
• Which question. "Who uses X" (technographic), "how big is it" (firmographic), "where does it spend" (spend, cloud spend), "is it in-market" (intent), "what changed lately" (operating signals), "does it sell to government" (government tools). Each question maps to a small set of tools. Running all fifteen is waste and clutter.
• Which user or account. If the user wants a person, use contact_search or contact_enrich only after the company is confirmed, so the contact is matched to the right organisation.

Confirm the scope in one short line ("Researching Acme Corp, the Delaware parent, for technology stack and spend. OK?") when the request is ambiguous. For a clear request, state it and proceed.

2. Choose the tool family by question

• Company identity and size: company_search, then company_firmographic.
• Technology in use: company_technographic (what they run and buy). Use company_install_time_series when the user asks how adoption changed over time.
• Money: company_spend for technology spend, company_cloud_spend only when cloud providers are the question.
• Buying behaviour: company_intent for topic-level intent; company_operating_signals for recent events that suggest timing.
• Contracts and vendors: company_contracts and company_fai for commercial relationships and the installed-base view. Read the definitions in the result before quoting them.
• Government: company_gov_opportunities and company_gov_relationships, covered in depth by the sibling government skill. Use them here only to confirm they exist.
• People: contact_search to find candidates, contact_enrich to fill in one known person. Never enrich a list in bulk without the user's scope.
• Public web context: web_search for news, announcements and anything not in the structured data. Treat the results as unverified sources until you read them.

Start narrow. One well-chosen tool that answers the question beats five partial answers.

3. Keep results small

Structured company results can be long. Ask for, and report, only the fields that bear on the question. Summarise lists to the top items plus a count ("showing 10 of 84"). When a result is paginated, fetch the next page only if the user needs more, not by default. Do not paste raw payloads into the answer.

4. Handle empty, partial and blocked results

• Empty result: distinguish "the company has no recorded data here" from "the name did not match". Retry once with a different identifier or spelling from company_search before concluding. Say which one it was.
• Partial result: report what came back and mark what is missing. Do not fill gaps from memory or from another company.
• Permission or sign-in error: the account may lack access to that data family or the session may have expired. Say which tool was blocked, tell the user to check their Phoenix sign-in and plan, and continue with the tools that work. Do not retry in a loop.
• Rate limit: stop, report the limit, and offer to continue later or narrow the scope.

5. Phoenix is read-only

Phoenix exposes lookup and search tools only. None of the fifteen tools creates, updates, sends or deletes anything in Phoenix or in the user's own systems. You can therefore run any read tool in this skill without an approval step. If a user asks you to write results into a CRM or to send a message, that action happens outside Phoenix, through another connector, and needs that connector's own approval rules. Do not present a Phoenix lookup as having saved, pushed or triggered anything.

Common patterns and traps

• Name match is not identity. Two companies sharing a brand, or a parent and its subsidiary, produce confident-looking numbers for the wrong entity. Confirm before quoting.
• Stale data looks authoritative. Install and spend figures are estimates with dates. Quote the basis and the period, not just the number.
• Modeled figures are not measured. Spend and intent are modeled from signals. Say "estimated" or "modeled" when the result does.
• Contact data goes stale faster than company data. Roles change; say when a contact was matched and recommend verification before outreach.
• Web search is a lead, not a fact. Open the source before stating a claim from it.
• The fifteen-tool temptation. A question about one company rarely needs more than three or four tools. Cite only the ones you used.

Output

Target: <company, confirmed by <domain/location/identifier used>>
Question: <one line>
Tools used: <list>
Findings:
- <finding> (source: <tool>, period/basis: <date or "modeled">)
Gaps: <tools blocked, empty results, identity uncertainty>
Read-only: no changes made in Phoenix.

Rules

• Do not quote a company figure until the company identity has been confirmed.
• Never present modeled, estimated or web-sourced figures as measured facts.
• Do not enrich, export or message a list of contacts without the user's explicit scope and yes.
• Do not repeat tool descriptions or dump raw payloads into the answer.
• Phoenix has no write tools here; if an action would write elsewhere, wait for the user's explicit yes and route it through the other connector.

Done when

• The target company or person is confirmed, or the user has accepted the uncertainty in writing.
• The answer uses only the tools the question needed, with a source and basis for each finding.
• Blocked, empty and partial results are named in the Gaps line, and nothing was filled in from memory.