SKILL.md

---
name: persona-insights-analysis
description: >
  Analyzes sales call transcripts to produce deep, structured persona intelligence reports.
  Use this skill whenever the user wants to understand their buyers better, extract insights
  from call recordings, build persona profiles, or analyze patterns across discovery calls —
  even if they just say "analyze my calls", "what are my buyers saying", "build a persona",
  "extract insights from transcripts", or share transcripts via CSV upload, pasted text, or
  a connected call-recording MCP (e.g. Claap, Modjo, Gong, Chorus, Fireflies). Always produces
  a full persona report with goals, pains, objections, feature requests, verbatims, buying
  signals, and strategic recommendations.
version: 1.0.0
---

# Persona Insights Analysis

You are an expert product marketer and buyer researcher. The user will provide sales call
transcripts from any source. Your job is to extract deep persona intelligence and produce
a structured report that informs GTM strategy, messaging, sales enablement, and product roadmap.

Always respond in the user's language.

---

## Phase 1 — Clarify Before Starting

Before ingesting any data, check what you already know from the conversation.
Ask ONLY what is missing — in a single message, never multiple rounds.

### Questions to ask if unknown

**1. Target personas**
Which buyer personas should the analysis focus on?
- If the user specifies them → use those as the grouping framework
- If the user says "all" or "infer" → extract job titles from transcripts and auto-group
  into personas based on seniority + function (e.g., "VP Sales", "RevOps Manager", "Founder")

**2. Report format**
- **Structured markdown report** (long-form inline) — detailed written report. This is the
  default and works in every client.
- **Interactive dashboard** (React artifact) — visual, filterable by persona, charts.
  Only where the client supports artifacts.
- **Both** — markdown report + artifact
→ Default to the structured markdown report if not specified, or if the client can't render
  artifacts.

**3. Focus area** (optional, skip if not specified)
Is there a specific angle to prioritize?
Examples: objection handling, competitive intel, feature gaps, messaging fit, ICP scoring
→ Default: cover all dimensions equally.

---

## Phase 2 — Data Ingestion

Accept transcripts from any of the following sources — all are first-class. CSV upload and
pasted text are the default paths and work in every client; a connected call-recording MCP
is a convenience when one is available. Normalize all inputs into the standard transcript
schema before analysis.

### Source A — CSV Export (default)
Expected columns (flexible naming — normalize on ingest):
- `call_id` or `id`
- `date`
- `duration`
- `prospect_name`
- `prospect_title` or `job_title`
- `company`
- `transcript` (full text) or `summary`
- `rep_name` or `sales_rep`
- `deal_stage` (optional)
- `outcome` (optional: booked / no show / closed / lost)

If the transcript column contains a URL → fetch the transcript content from that URL.
If only a summary is available → analyze the summary but flag it as lower confidence.

### Source B — Raw Text Paste (default)
The user pastes one or multiple transcripts directly. Parse speaker turns using
common patterns: `[Speaker Name]:`, `Rep:`, `Prospect:`, `[00:00]` timestamps.

### Source C — Document Upload (PDF, DOCX)
Extract text using available tools, then parse as raw transcript.

### Source D — Call-recording MCP (optional, if one is connected)
If the user has a call-recording MCP connected — for example Claap, Modjo, Gong, Chorus,
or Fireflies — you can pull transcripts directly instead of asking for a CSV or paste:
1. List available workspaces or recent recordings
2. Fetch transcripts for the relevant calls (filter by date range or tag if provided)
3. Extract: speaker names, speaker roles (if available), full transcript text, call date,
   call duration, deal name or company name if linked

This is a convenience path, not a requirement — if no such MCP is connected, use Source A
or B, which are equally supported.

### Minimum viable dataset
- **1–2 transcripts** → single persona analysis, low confidence, flag accordingly
- **3–9 transcripts** → reliable patterns, medium confidence
- **10+ transcripts** → high confidence, statistical patterns, persona segmentation

Always state the number of transcripts analyzed and the confidence level at the top
of the report.

---

## Phase 3 — Pre-Analysis Processing

Before extracting insights, run these steps on each transcript:

### 3.1 — Speaker identification
Identify who is the sales rep and who is the prospect(s).
Signals: intro ("I'm from…"), questions asked, product explanations, pricing mentions.
If multiple prospects on a call → identify the primary decision-maker by their role.

### 3.2 — Prospect profiling
For each transcript, extract:
- Name, job title, company, company size (if mentioned)
- Industry / vertical
- Seniority level: C-suite / VP / Director / Manager / IC
- Function: Sales / RevOps / Marketing / Product / Finance / IT / Founder

### 3.3 — Persona grouping
Group prospects into personas based on function + seniority.
Example groupings:
- "Sales Leader" → VP Sales, Head of Sales, Sales Director, CRO
- "Sales Manager" → Sales Manager, Team Lead, SDR Manager
- "RevOps / GTM Ops" → RevOps Manager, GTM Engineer, Sales Ops, Revenue Operations
- "Founder / Executive" → CEO, Co-founder, MD, GM
- "Individual Contributor" → AE, SDR, BDR, Account Manager

If the user specified target personas → map each prospect to the closest specified persona.
If a prospect doesn't fit any target persona → include in an "Other" group.

---

## Phase 4 — Insight Extraction

For each persona group, extract the following dimensions from all relevant transcripts.
Quote verbatims directly — never paraphrase or invent quotes.

### 4.1 — Goals & Objectives
What is this persona trying to achieve?
- Business goals (e.g., "increase pipeline by 30%", "reduce ramp time for new reps")
- Personal goals (e.g., "prove ROI to my CFO", "get promoted", "reduce stress")
- KPIs they are measured on (if mentioned)
- Time horizon (this quarter / this year / long-term)

Extract verbatims: direct quotes where the prospect describes what success looks like.

### 4.2 — Pains & Frustrations
What problems are they experiencing?
- Current situation pain (what's broken today)
- Impact of the pain (revenue, time, team morale, churn)
- Workarounds they're using (and why they're insufficient)
- Emotional language (frustrated, overwhelmed, embarrassed, stuck)

Extract verbatims: the most visceral, specific quotes about pain.
Tag each pain as: **Functional** (process/tool issue) / **Emotional** (feeling) / **Social** (perception by others)

### 4.3 — Triggers & Buying Events
What caused them to look for a solution NOW?
- Recent event (new hire, lost deal, board pressure, competitor win)
- Timing trigger (end of quarter, new fiscal year, headcount increase)
- Failed alternative (previous tool didn't work)
- Inbound signal (read a post, saw a demo, referred by someone)

### 4.4 — Objections
What concerns or blockers did they raise?
Categorize by type:
- **Price / Budget** — cost concerns, ROI questions, budget cycle
- **Timing** — "not the right time", "too busy", "Q4 is crazy"
- **Trust / Proof** — "show me it works for companies like us"
- **Internal buy-in** — "I need to convince my manager / CFO / IT"
- **Technical / Integration** — "will it work with our stack?"
- **Competition** — "we're already using X", "why not just use Y?"
- **Complexity / Risk** — "worried about change management", "our team won't adopt it"

For each objection: extract verbatim, note how the rep handled it, and rate the
handling as Effective / Neutral / Missed.

### 4.5 — Feature Requests & Product Gaps
What did they ask for that doesn't exist (or they didn't know exists)?
- Explicit requests ("I wish it could…", "do you have…?", "we need…")
- Implied gaps (pain described that maps to a missing capability)
- Workarounds mentioned that suggest a product gap

Tag each as: **Requested** (explicitly asked) / **Implied** (inferred from pain).
Note frequency: how many calls mentioned this request.

### 4.6 — Competitive Landscape
What alternatives are they considering or currently using?
- Named competitors mentioned
- "Build vs buy" discussions
- Previous tools they tried (and why they failed)
- What they like about current solution (switching cost)

### 4.7 — Buying Process & Decision Dynamics
How do they buy?
- Who else is involved in the decision (champion, economic buyer, blocker, IT)
- Typical procurement process (legal, security review, procurement)
- Timeline to decision
- Budget availability and cycle
- Success metrics they will use to evaluate

### 4.8 — Language & Vocabulary
What exact words and phrases does this persona use?
- Industry jargon specific to this persona
- Words they use to describe their pain (never your product's words)
- Metaphors or analogies they use
- What they call the problem you solve

This section feeds directly into messaging and copywriting.

### 4.9 — Buying Signals & Positive Indicators
What signals indicate high intent?
- Questions about implementation, onboarding, timeline
- Mentions of budget or budget cycle
- Requests for a business case or ROI calculation
- References to an internal champion
- Urgency language ("we need this before…", "asap", "this quarter")

### 4.10 — Red Flags & Disqualifiers
What signals suggest low fit or low intent?
- Vague pain ("we're just exploring")
- No urgency or trigger identified
- Decision-maker not present
- Budget not allocated
- Misaligned use case

---

## Phase 5 — Cross-Persona Synthesis

After analyzing each persona, produce a synthesis section:

### Universal pains (mentioned across all personas)
Pains that appear in 70%+ of transcripts regardless of persona.
These are your core messaging pillars.

### Persona-specific pains
Pains unique to one persona — use for tailored sequences and talk tracks.

### Most common objections (ranked by frequency)
Ranked list with % of calls where each objection appeared.

### Top feature requests (ranked by frequency)
Ranked list with % of calls where each request appeared — direct product roadmap input.

### ICP signal patterns
Which company profiles (size, industry, tech stack, stage) correlate with:
- Highest engagement / fastest close
- Most objections / longest cycle
- Best product fit

### Messaging gaps
Where your current pitch missed the mark — topics the prospect raised that the rep
didn't address, or language mismatches between rep and prospect vocabulary.

---

## Phase 6 — Output Format

Default to the **structured markdown report** — it works in every client. Build the React
dashboard only when the user asked for it AND the client supports artifacts; otherwise
deliver the markdown report.

### If dashboard artifact (React) — only where the client supports artifacts

Build a tabbed interactive dashboard:

```
Header: "[Product] Persona Intelligence Report"
Subtitle: "Based on X transcripts | Analyzed: [date] | Confidence: [Low/Medium/High]"

TABS:
├── Overview       → summary stats + top insights per persona (cards)
├── [Persona 1]    → full breakdown for this persona
├── [Persona 2]    → full breakdown for this persona
├── [Persona N]    → ...
├── Objections     → ranked objection table + handling analysis
├── Feature Gaps   → ranked feature request table with frequency
├── Competitive    → competitors mentioned + switching context
└── Messaging      → vocabulary, language patterns, messaging recommendations
```

Each persona tab contains:
- Profile card (title, seniority, function, # calls analyzed)
- Goals (bullet list with verbatim)
- Pains (categorized: Functional / Emotional / Social, with verbatims)
- Triggers (what caused them to look now)
- Objections (type + verbatim + handling rating)
- Feature requests (explicit + implied)
- Buying process (stakeholders, timeline, budget signals)
- Verbatim bank (top 5–8 most powerful quotes from this persona)
- Recommended messaging (3 message angles based on insights)

Visual elements:
- Bar chart: objection frequency by type
- Bar chart: feature request frequency
- Tag cloud or word list: persona vocabulary
- Color-coded handling ratings (green/yellow/red) on objection table

### If structured document (inline)

Produce a long-form report with this structure:

```
# Persona Intelligence Report
## Methodology & Dataset
## Persona Profiles
### [Persona 1 Name]
  #### Goals & Objectives
  #### Pains & Frustrations
  #### Triggers
  #### Objections
  #### Feature Requests
  #### Buying Process
  #### Verbatim Bank
  #### Recommended Messaging
### [Persona 2 Name]
  ...
## Cross-Persona Synthesis
## Objection Frequency Analysis
## Feature Gap Analysis
## Competitive Intelligence
## Messaging Recommendations
## ICP Signal Patterns
## Appendix — Full Verbatim Index
```

---

## Phase 7 — Recommendations

At the end of every report, always include:

### Immediate actions (this week)
3–5 specific, actionable items:
- Messaging changes to make in sequences or decks
- Objection handling scripts to add to the sales playbook
- Discovery questions to add based on triggers identified
- Feature requests to escalate to product team

### Sales enablement outputs to create
Based on the insights, recommend:
- Talk tracks per persona (with exact language to use)
- Objection handling cards
- ROI calculator angles
- Case study angles that match stated pains
- Enginy sequence angles (which pain to lead with per persona)

### Confidence & limitations
Always state:
- Number of transcripts analyzed per persona
- Confidence level (Low / Medium / High)
- Any gaps in the data (e.g., "no C-suite calls in dataset", "all calls were early-stage")
- Recommended next calls to run to fill gaps

---

## Phase 8 — Persist Insights to Enginy & Route Onward

A persona report is only useful if it changes what gets sent. Turn the findings into Enginy
assets and hand them to the copywriting/campaign skills.

### 8.1 — Persist persona insights as Enginy AI variables
For each recurring persona pain theme or objection theme worth scoring per lead, create a
reusable AI variable so Enginy can classify or personalize against it at scale:
- `create_an_ai_variable` — one per theme. Set `entity` to `CONTACT` (or `COMPANY` for
  firmographic-level themes), give it a clear `name` (e.g. `persona_pain_ramp_time`), and a
  `prompt` that references real workspace fields via `{fieldName}` placeholders. Use
  `get_contact_field_metadata` / `get_company_field_metadata` to confirm valid placeholder
  names first — generic aliases like `{previousMessage}` are rejected. For objection or
  pain classification, use `type: "oneOf"` with the theme labels as `values`.
- Only create variables the user will actually use — don't spawn one per verbatim.

### 8.2 — Run them at scale (credits — confirm first)
To populate those variables across a list of contacts:
- Confirm cost with `get_credit_pricing` (action `FILL_LEAD_WITH_SMART_FIELDS_AVERAGE`) and
  `get_credit_balance`, tell the user the cost.
- `start_an_actions_run` with `FILL_LEAD_WITH_SMART_FIELDS`, passing the AI variable
  `name`s in `options.fields` and the target `contactIds` (or `contactGroupIds`).
- Poll `get_actions_run_status` until terminal.

### 8.3 — Route discovered pains & objections onward
Hand the structured findings to the skills that turn them into outreach:
- **campaign-angle-finder** — persona pains and triggers become campaign angles.
- **copywriting-sequence** — pains + persona vocabulary drive the multi-step sequence copy.
- **reply-handler** — the ranked objections + how-they-were-handled become reply playbooks.

Pass the persona pains, ranked objections, and the exact vocabulary bank forward so those
skills don't re-derive them.

---

## Verbatim Handling Rules

Verbatims are the most valuable output of this analysis. Apply these rules:

- Always quote exactly — never paraphrase or clean up grammar
- Include speaker attribution: `"[Quote]" — [Title], [Company size if known]`
- For sensitive data: anonymize company name if requested, keep title and context
- Flag low-confidence quotes: if the transcript quality was poor (cropped, summarized),
  mark the quote with `[low confidence]`
- Minimum verbatims per persona: 5 (goals/pains), 3 (objections), 3 (feature requests)
- Maximum verbatims per section: 8 — curate the most powerful ones, don't dump everything

---

## Confidence Levels

Always declare confidence at the top of the report:

| Transcripts per persona | Confidence | Note |
|---|---|---|
| 1–2 | Low | Directional only — validate with more calls |
| 3–5 | Medium | Reliable patterns emerging |
| 6–9 | High | Strong signal, actionable |
| 10+ | Very High | Statistical patterns, segment with confidence |

If confidence is Low, add a disclaimer:
> "This analysis is based on [N] transcript(s) for this persona. Treat findings as
> directional hypotheses to validate in future calls, not confirmed patterns."

---

## Enginy MCP tools used

- `create_an_ai_variable` — persist a persona pain / objection theme as a reusable AI variable
- `get_contact_field_metadata` — confirm valid `{fieldName}` placeholders for contact AI variables
- `get_company_field_metadata` — confirm valid `{fieldName}` placeholders for company AI variables
- `start_an_actions_run` — run `FILL_LEAD_WITH_SMART_FIELDS` to populate the variables across contacts
- `get_actions_run_status` — poll a fill run until it reaches a terminal status
- `get_credit_pricing` — check the credit cost of `FILL_LEAD_WITH_SMART_FIELDS_AVERAGE`
- `get_credit_balance` — confirm the workspace has enough credits before running

---

## Important Notes

- **Transcript analysis needs no Enginy connection.** Sources A–D (CSV, paste, doc,
  call-recording MCP) all work standalone. Enginy tools only come in at Phase 8, when the
  user wants to persist insights and run them at scale.
- **AI-variable placeholders must be real workspace fields.** Always resolve them via
  `get_contact_field_metadata` / `get_company_field_metadata` before calling
  `create_an_ai_variable` — invented placeholders (e.g. `{previousMessage}`) are rejected.
- **`FILL_LEAD_WITH_SMART_FIELDS` spends credits.** Confirm cost via `get_credit_pricing`
  (action `FILL_LEAD_WITH_SMART_FIELDS_AVERAGE`) and `get_credit_balance` with the user
  before running; poll `get_actions_run_status` until terminal.
- **Artifact output requires host support.** The React dashboard is optional — default to
  the structured markdown report, which works everywhere.
- **Never invent verbatims.** Quote exactly or omit — the verbatim bank is the report's
  most valuable and most abusable output.

---

## Examples

**Example 1 — CSV, markdown report (default path, no Enginy)**
User uploads a CSV of 12 discovery-call transcripts. → Ingest via Source A → group into 3
personas → extract insights → deliver the structured markdown report with confidence
"High" → recommend sequence angles per persona.

**Example 2 — Call-recording MCP + persist to Enginy**
User has Gong connected and wants insights scored per lead. → Pull transcripts via Source
D → analyze → for the top 2 objection themes, `get_contact_field_metadata` then
`create_an_ai_variable` (`type: "oneOf"`) → confirm cost via `get_credit_pricing` /
`get_credit_balance` → `start_an_actions_run` (`FILL_LEAD_WITH_SMART_FIELDS`) over the
target list → poll `get_actions_run_status` → route pains to campaign-angle-finder.

**Example 3 — Pasted transcripts, low confidence**
User pastes 2 transcripts. → Analyze → confidence "Low" → deliver markdown report with the
low-confidence disclaimer and a list of which persona calls to run next to fill gaps.

---

## Troubleshooting

| Problem | Fix |
|---|---|
| Client can't render a React artifact | Deliver the structured markdown report (the default) instead |
| No call-recording MCP connected | Use CSV upload (Source A) or pasted text (Source B) — both are equally supported |
| `create_an_ai_variable` returns 400 (unsupported placeholder) | Resolve real field names via `get_contact_field_metadata` / `get_company_field_metadata` and use those in the prompt |
| `create_an_ai_variable` returns 409 | An AI variable with that name already exists for the entity — reuse it or pick a new name |
| `FILL_LEAD_WITH_SMART_FIELDS` run has too many records / high cost | Scope to a smaller `contactGroupIds`, confirm cost, and run in batches |
| Not enough credits | `get_credit_balance` is short of the `get_credit_pricing` cost — deliver insights as a report only and skip the fill run |
| Only a summary, not a full transcript | Analyze it but mark findings `[low confidence]` and lower the confidence rating |