Phoenix PVP-PQS Framework

Produce a single Phoenix-branded HTML executive briefing that walks an HG Insights customer through pain-qualified-segment plus permissionless-value-proposition outbound, worked end-to-end against one of their actual greenfield targets. The briefing ends with a fully drafted PVP email, a message so specific and valuable the target would forward it to a colleague even if they never buy.

The canonical reference is the DDN-Nebius worked example shipped under /samples/phoenix-pvp-pqs-ddn-nebius.html. Read it before drafting. Every layout decision, signal-board pattern, and PVP rhythm came out of that run.

When to use

• Marketing Ops, field marketing, or RevOps need a value-first outbound briefing for a named target.
• A CSM is preparing for a customer touchpoint that asks "show me how Phoenix MCP would prove this works on our prospects."
• An SE or RevOps lead needs a worked example to demo Phoenix MCP end-to-end against a specific account.

Triggers include "PVP showcase", "PQS / PVP briefing", "pain-qualified segment", "outbound demo for [customer]", "DDN-style briefing for [target]". Compose with the PVP Composition skill for the email-body craft and the Phoenix HTML Briefing Structure skill for the layout spec.

Inputs

Confirm before starting. If anything required is missing, ask once, then proceed.

Required	What it is
customer	The HG Insights customer this briefing is for (the audience reading it)
customer_category	One sentence: what they sell
customer_differentiators	Two sentences: what makes them defensible
customer_references	3 to 5 named customers verifiable on the customer's public site
customer_competitors	2 to 4 named competitors

Optional	What it is
target	A specific named prospect for the worked example. If not provided, pick one using the Phase 1 rules.
sender	Customer-side executive whose name signs the PVP (President, CRO). Default to title only.
industry_trends	Recent contracts, regulations, or capacity announcements to weave in

Runtime: five phases, one pass

Surface the choices you made (target selection, PQS naming, sources used) in chat after the HTML is built, so the user can correct anything before the next iteration.

Phase 1: Customer and target context

1. Web-search the customer. Confirm current positioning, named reference customers, and the executive team. Don't trust training data.
2. Pick the target if not supplied. Apply these rules in order:
   • Greenfield only. No public partnership, customer relationship, or co-marketing with the customer. Verify with two web searches: "[customer] [target] partnership" and "[customer] [target] customer". If either turns up a relationship, pick a different target.
   • Public commitments large enough to anchor math. Prefer SEC filers, named hyperscaler contracts, or publicly disclosed capacity announcements.
   • At meaningful scale in the customer's ICP. Not the biggest possible name. The most credible "we should already be talking" name.
   • Has a named incumbent in the customer's competitive set. Makes the workload-fit argument concrete.
3. Capture greenfield verification in chat. State which searches you ran and what they returned. This is the first claim the user will check.

Phase 2: Phoenix MCP data gather

Run the standard dossier sequence on the target. Capture every signal with the originating tool call: you need these for the anatomy block in the briefing.

• company_firmographic: basics, parent/subsidiary, geo
• company_operating_signals: AI maturity, cloud posture, network modernization
• company_technographic sorted by intensity: top 20 to 30 products
• company_install_time_series filtered to the customer's product categories
• company_intent: TrustRadius buyer-intent signals and bidstream context
• sec_full_text_search: if the target is public, search for ticker, contract values, capacity, partnerships
• sec_filing_section: extract the named contract or commitment sections
• web_search: the target's product, hardware, partner, customer pages; named partnership announcements; peer competitor partner counts

Newly public or recently spun-out targets: HG technographic depth may be sparse. The absence is itself a signal. Call it out in the signal board. Use SEC and primary-source web pages to compensate.

Build a working signals table with at least 9 entries. Each entry: tool tag, intensity tag (the "hot" red badges are reserved for the 3 to 4 figures the PVP math depends on), name, and one or two sentences of detail with the key number wrapped for emphasis.

Phase 3: PQS naming

The pain-qualified segment is one specific, data-detectable situation the target is in. Headline format:

The [specific situation or commitment] with [the missing piece].

Examples that travel:

• "The 5 GW commitment with a single-vendor storage tier" (greenfield neo-cloud)
• "The 60% GPU expansion with no committed SLA-tier storage partner" (expansion archetype)

The pain-detail paragraph beneath the headline does the math: takes the target's public commitments, applies the relevant industry attach rate, lands at a credible dollar envelope. Always name the source (SEC 6-K, IDC report, NVIDIA press, etc.) in the paragraph.

Phase 4: PVP composition

Hand off to the PVP Composition skill for the body-craft. The condensed structure is below; the composition skill is canonical.

PVP body, in order:

1. Thesis paragraph. Their situation in one breath, the unique insight in one sentence.
2. Three structural observations. Each names a specific workload class or procurement scenario, identifies the failure mode, gives a forward-looking timing cue. Customer references appear inside these observations, not at the headline.
3. Architectural pattern recognition. Connect the target's heritage or strategic position to why the customer's category exists.
4. Multi-vendor industry pattern. What peers at the target's scale do, with a named reference, and why.
5. Math for both sides. What the target gets (operational wins). What the customer gets (a small percentage of the target's envelope).
6. Soft close. "If [specific scenario], we'd want to know." Never a hard CTA.

Every figure in the PVP must trace to either a Phoenix MCP tool call (Phase 2) or a named public source. Build the four-cell anatomy block underneath the PVP and confirm every number maps. If a number doesn't map, cut it.

Phase 5: HTML build

Hand off to the Phoenix HTML Briefing Structure skill for the layout spec. The bundled reference at /samples/phoenix-pvp-pqs-ddn-nebius.html is the canonical layout. Mirror its structure.

The final HTML is one self-contained file: inlined CSS in a <style> block, Google Fonts loaded by URL, no external stylesheets, no build step, no JavaScript.

Variants

The same workflow runs three configurations. Default is greenfield.

Variant	When	What changes
Greenfield (default)	Customer has no relationship with target	PQS argues for an unclaimed tier. PVP names the incumbent.
Expansion	Customer is already named alongside competitors	PQS argues which workloads belong to the customer's tier specifically. PVP argues tier ownership instead of naming an incumbent.
Archetype	Target is a customer archetype, not a single account	Pain block names the archetype. PVP is a template the customer's SDRs fill in. Signal board uses representative figures with an asterisk.

Common failure modes and the fix

Failure mode	Fix
Picked a target where the customer already has a relationship	Always web-search the partnership pair before committing. Training data is unreliable on partnerships.
PVP reads as a credentials sheet	Lead with workload-class observations. Customer references go inside the structural insight, not at the headline.
Generic AI-GTM language	Use the customer's industry vocabulary throughout, including in the concept examples in the briefing.
Math doesn't tie to public sources	Build the four-cell anatomy block. Every figure traces to a Phoenix tool or a named public source. If it doesn't trace, cut it.
HTML drifts from Phoenix system	Read the Phoenix HTML Briefing Structure skill first. One gradient text. One primary button.
Em dashes, rule-of-three, rhetorical questions	Run the editorial guardrails in the PVP Composition skill as a final pass before writing the HTML.