<technical_accuracy> NON-NEGOTIABLE. Before ANY customer-facing string (call talking point, email, task body), verify every product, spec, tier, integration, and price with Epiphan AI (search_product_catalog, Epiphan Knowledge search) per the epiphan-ai-mcp-guide-skill, and run brand voice through the Epiphan Brand MCP (get_persona, get_writing_style, check_my_copy). Never quote a spec or a cloud tier from memory. The expansion math (units, usage, idle) is data; the pitch is brand + spec gated. </technical_accuracy>

<quick_start> Trigger: "Run expansion", "Build expansion targets", "Who should I expand?" (default cadence: Monday 8:00 AM CST scheduled task)

Inputs:

Window — trailing 90 days of activity signal (rolling). Default 90.
Geo — default USA + Canada.
Owner scope (optional) — Tim 87486452; pass a rep's owner_id to focus their book, else treat as team pool.
Min footprint — account owns >= 1 Pearl OR an active Epiphan Cloud subscription.

Outputs:

Excel workbook: Summary · Expansion Targets (all, ranked) · one tab per trigger · Review (no signal / churned).
Drafted HubSpot CALL tasks + enrichment notes for High-priority accounts (admin-scoped, draft-first).
Sidecar: ~/.claude/skill-analytics/last-outcome-install-base-expansion-engine-skill.json (see Outcome Sidecar below)

Dependencies (Epiphan-native first — Gate D):

mcp__Epiphan_Ai__analytics_search_by_email / analytics_get_device — Pearl fleet by registrant + serial.
mcp__Epiphan_Ai__ask_agent — Stripe Cloud (Connect/Unify) usage, renewals, growth/churn signals; cross-data device↔revenue.
mcp__Epiphan_Ai__export_query_csv — account rollup SQL (escape hatch, read-only).
mcp__Epiphan_Ai__crm_get_customer_orders / query_dataset (revenue) — purchase history + last-order recency.
mcp__Epiphan_Ai__sales_brief — one-shot account context before routing.
mcp__Epiphan_Ai__qualify_lead — ATL/BTL (power_level), region, junk (Gate A).
mcp__Epiphan_Ai__enrich_contact + Apollo (apollo:enrich-lead) — title/LinkedIn/phone on the expansion buyer.
xlsx skill — build the workbook. Epiphan Brand MCP (check_my_copy) + search_product_catalog — any copy. </quick_start>

Gate 0 — Owned, not greenfield. Keep only accounts with an EXISTING owned relationship: lifecycle = Customer, or a prior closed-won order, or an active Stripe Cloud subscription. If there is no owned relationship, it belongs to greenfield-pearl-tracker-skill, not here. Drop it.

Gate A — Dedupe + qualify. Roll up by registrable email domain (eTLD+1), so av.stanford.edu and stanford.edu are ONE account. Run qualify_lead on the chosen contact for power_level (atl/btl/unknown), region, and junk. If power_level = unknown, fall back to the vertical decision-maker title pattern; pass powerLevelOverride when you know the real authority.

Gate B — Device + cloud signal outranks title. Owned-device count and live Stripe usage are stronger buying signals than a cold title. An account that owns 6 Pearls and is at 90% of its Connect limit is a hotter call than a fresh ATL with no footprint. Use the ACCOUNT-LEVEL fleet rollup ("owns N Pearls across M sites"), never a single registrant email, to set priority.

Gate C — AE exclusion with reactivation. Exclude accounts with an OPEN deal owned by an AE — Lex Evans (82625923) or Phillip Sandler (190030668) — to avoid double-touch. Exception: re-include if BOTH notes_last_contacted is NULL or > 90 days AND no open (non closed-won/closed-lost) deal exists. Tag those REACTIVATED. Expansion into an account with a healthy open deal is the AE's move, not the SDR's — flag it to the AE via ae_handoff instead.

Gate D — Epiphan-native + spec/brand. Prefer Epiphan tools over generic. No spec or tier from memory (verify via catalog). No outbound copy without the brand gate.

Geo: USA + Canada. Suppression: opted-out, hard-bounced, touched within 2 days, or in an active Apollo sequence → drop.

Expansion triggers (the core IP)

Each owned account is tested against these signals. An account can fire more than one; rank by the highest-value trigger present. The product moves below are DIRECTIONAL — confirm the exact product, tier, and fit with search_product_catalog before it reaches a customer.

#	Trigger	Signal (data)	Directional play (verify before pitch)
1	Near capacity	High `util_pct` (low idle) across the fleet, lifetime > 30d so it's real adoption	Add encoder capacity; standardize on current-gen Pearl
2	Multi-site standardize	>= 3 Pearls across multiple cities/subdomains, mixed families	Fleet standardization + central management (Edge/Unify)
3	Cloud near limit / renewal	Stripe usage approaching contract limit, or renewal window < 90d (via `ask_agent`)	Tier upgrade / renewal expansion on Connect or Unify
4	Hardware refresh	Aging family (e.g. older Pearl) with high lifetime + active use	Refresh to current-gen; trade-in / fleet modernization
5	Hardware, no cloud (attach)	Owns Pearls, no active Stripe/cloud subscription	Attach Epiphan Cloud (Edge/Connect/Unify) to the fleet
6	Cloud, declining usage (save)	Stripe usage trending down quarter-over-quarter	Defensive expansion / adoption save before renewal churn
7	New department land	A new subdomain of an existing customer just registered	Cross-sell into the new dept; multi-thread the account

Triggers 1, 3 and 5 are the highest-yield in practice: capacity pressure, renewal pressure, and the cloud attach on an all-hardware fleet.

1. Pull the owned install base

Use analytics_search_by_email across known account domains and/or export_query_csv to roll devices to the account: per account return unit_count, pearl_families, distinct sites (cities/subdomains), util_pct (= 100 − idle%), max_lifetime_days, last_check, and last_order_date. Read utilization with care (per greenfield notes): units with lifetime <= 7d read provisionally high; high lifetime + old last_check + low util = a re-registered old device, not live adoption.

2. Layer in cloud + revenue

For each account ask ask_agent for Stripe Cloud usage: current usage vs contract limit, renewal date, and quarter-over-quarter trend (growing / flat / declining). Pull order recency via crm_get_customer_orders or query_dataset (revenue). This is what separates trigger 3/5/6 from each other.

3. Apply gates

Run Gate 0 (owned-only), Gate A (dedupe + qualify), Gate B (device+cloud priority), Gate C (AE exclusion / reactivation), geo + suppression. Accounts with a healthy AE-owned open deal → route to the AE via ae_handoff, drop from list.

4. Fire triggers + classify

For each surviving account, evaluate the 7 triggers, attach every one that fires, and set the lead trigger (highest-value). Classify Segment (End Customer / Production·Rental / Integrator·Reseller), ICP vertical + score, and BDR Priority:

High — End customers in Gov / Live Events / Higher Ed / Corporate AV firing trigger 1, 3, or 5.
Medium — K-12 + HoW end customers, production/rental, or accounts firing trigger 2/4/7.
Low — integrators/resellers (partner motion), or trigger 6 with no other signal.

5. Build the MEDDIC expansion play (gated)

Per High/Medium account, write ONE concrete next move. The expansion angle makes MEDDIC easier — you already have the Champion (the registrant) and the Metric (their current usage). Frame the play around the trigger's "metric that matters" (e.g. "you're at 90% of your Connect hours — here's the path to headroom"). Verify the product/tier/spec via search_product_catalog and run any written line through check_my_copy before it lands in a task.

6. Enrich the buyer

enrich_contact (free) then apollo:enrich-lead for title / LinkedIn / seniority / phone on the expansion decision-maker. Title routes the play: an "AV Manager / Director of Learning Spaces" is the fleet-standardization buyer; a "Director of IT / Procurement" is the renewal buyer.

7. Output

Workbook (via xlsx skill):

Summary — counts by priority, trigger, vertical; total owned units and active cloud subs in scope; top 5 "call today".
Expansion Targets — all accounts, ranked High→Low, autofilter, frozen header, trigger + priority color-coded.
One tab per trigger — focused cuts for review with Victor / AEs.
Review — owned accounts with no live signal, or churned/declining-only, parked for nurture.

HubSpot (admin-scoped, draft-first): for High accounts, draft a CALL task (hubspot_create_contact_task, taskType: CALL) for the rep with the trigger + gated talking point, and an enrichment note (hubspot_create_contact_note). Never auto-send; these are queued for the rep.

Sidecar: write last-outcome-install-base-expansion-engine-skill.json (counts by trigger

priority, units/cloud in scope, runtime) — schema in Outcome Sidecar below.

Present the .xlsx with present_files (Cowork) or as a file path in Claude Code.

<house_rules> Customer-facing skill. Before output, run the gates in order (details: ~/.claude/skills/epiphan-house-rules-skill/reference/gates.md): S: search_product_catalog (Epiphan AI) or Epiphan Knowledge search before any product claim. B: check_my_copy on every customer-facing string. Q: qualify_lead right after the candidate pull, before tiering/enrichment/drafts. D: outbound text becomes a Gmail draft, never a send. Identifiers (owner IDs, portal, emails, seats) come from reference/identifiers.md in that skill — do not restate them here. On any gate failure follow reference/self-healing.md (retry, degrade with a flag, alert Tim, halt) and append a line to ~/.claude/skill-runs/.jsonl. </house_rules>

<success_criteria>

Gate 0 enforced: every account on the list has an owned relationship (Customer lifecycle, closed-won order, or active Stripe cloud sub); greenfield accounts dropped
Device fleet and cloud usage rolled up to the account (eTLD+1), never a single registrant email; unit_count, sites, util_pct, cloud usage vs limit, renewal date populated where data exists
qualify_lead run on the chosen contact; ATL/BTL, region, junk recorded; AE-owned open deals excluded or handed off via ae_handoff (reactivation tagged REACTIVATED)
Every account carries a lead trigger (1-7), all firing triggers, ICP vertical + score, Segment, and BDR Priority
Every product/tier in a talking point verified via search_product_catalog; every written line cleared by check_my_copy
Workbook delivered with the fixed column order and tabs (Summary · Expansion Targets · per-trigger · Review)
CALL tasks + notes drafted only for High accounts, admin-scoped, never auto-sent
Outcome sidecar written (see below) </success_criteria>

Output contract (do not change column order)

Tabs: Summary · Expansion Targets · one per trigger · Review.

Weekly cadence

Monday 8:00 AM CST, trailing 90-day signal window, USA + Canada, draft-first (no auto-send). Same columns/tabs each week so output is consistent and the team is interchangeable. Pairs with greenfield-pearl-tracker-skill (Friday).

GTME lens

GTM motion: activates land-and-expand on the install base, the highest win-rate motion Epiphan has and the one a GTM hire is expected to own.
Operational leverage: replaces manual fleet + Stripe digging with one ranked, gated, callable list; concentrates dials on accounts already sending a buying signal, lifting connect→demo and shortening time-to-expansion.

Roadmap (v1.1+)

Auto-rollup of subdomains to parent org via the greenfield verify query.
Slack digest of top-10 expansion targets to the rep each Monday.
Win-rate-weighted trigger ranking once yield analytics (pipeline-yield-analytics-skill) has 1-2 quarters of closed-loop data.
Auto-ae_handoff when an expansion account already has an open AE deal.

Outcome Sidecar

Write to ~/.claude/skill-analytics/last-outcome-install-base-expansion-engine-skill.json (path MUST be outside the repo). The PostToolUse sweep hook ingests it into outcomes.jsonl.

{
  "ts": "{ISO-8601 UTC now}",
  "skill": "install-base-expansion-engine-skill",
  "version": "1.0.0",
  "variant": "default",
  "status": "success | partial | error",
  "runtime_ms": 0,
  "metrics": {
    "owned_accounts_scanned": 0,
    "accounts_after_gates": 0,
    "high": 0,
    "medium": 0,
    "low": 0,
    "by_trigger": {"1": 0, "2": 0, "3": 0, "4": 0, "5": 0, "6": 0, "7": 0},
    "owned_units_in_scope": 0,
    "active_cloud_subs_in_scope": 0,
    "ae_handoffs": 0,
    "call_tasks_drafted": 0
  },
  "error": null,
  "session_id": "{session id or null}"
}

status = "success" when device analytics AND cloud/Stripe signal were both pulled; "partial" if one source (e.g. ask_agent Stripe usage) was unavailable and triggers 3/5/6 could not be evaluated (fill error); "error" only if no workbook could be produced.

install-base-expansion-engine-skill

Install-Base Expansion Engine — v1.0.0