# Call Insight Extraction > Extract structured, tagged insights from a customer call transcript — pain points, feature asks, objections, buying signals, and action items — ready to route to a backlog or share with a team. Use whenever a call transcript, meeting recording, or customer conversation needs to become a shareable summary rather than sit as raw notes, especially for sales calls, customer success check-ins, user research interviews, or support escalations. - Skill: `saurabhships/call-insight-extraction` (Agent Skill) - Install (CLI): `npx skillmds@latest add saurabhships/call-insight-extraction` - Raw SKILL.md: https://api.skillmd.com/api/skills/saurabhships/call-insight-extraction/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - Author: saurabhships (https://skillmd.com/u/saurabhships) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/saurabhships/call-insight-extraction --- # Call Insight Extraction ## Why this exists A raw transcript is not an insight. Two failure modes show up constantly when this is done ad hoc: 1. **Recency/loudness bias** — whoever spoke last, or most emotionally, dominates the summary, even if it wasn't the most important thing said. 2. **No routing** — the insight gets written up once, read once, and then lost, because it was never tagged in a way that lets it accumulate with similar signals over time. This skill fixes both: a fixed extraction structure (so nothing depends on what happened to stand out), and a tagging taxonomy (so today's call connects to last month's calls). ## Process ### 1. Capture context first Before extracting anything, note: - Who was on the call (customer role/seniority, internal attendees) - Account context if known (segment, plan tier, deal/relationship stage) - Call type (sales, onboarding, QBR, support escalation, user research) This context changes how everything else should be weighted — a passing comment from a VP on a renewal call carries differently than the same comment from a trial user's onboarding call. Don't drop this just because it feels like metadata. ### 2. Extract into fixed categories Go through the transcript once per category rather than trying to catch everything in one pass. For each category, pull only what's actually present — don't force an entry into every bucket: - **Pain points** — problems the customer described, in their words, independent of whether they asked for anything specific - **Feature requests / asks** — explicit requests, including throwaway "it'd be nice if" comments - **Objections / concerns** — anything that sounded like hesitation, doubt, or a blocker - **Competitive mentions** — any other tool, vendor, or internal build mentioned, and in what context (replacing us, replaced by us, used alongside us) - **Buying / expansion signals** — budget mentions, timeline mentions, other stakeholders referenced, expansion use cases - **Action items** — anything either party committed to doing - **Notable verbatims** — at most 2–3 short quotes that capture something precisely — reserve these for lines where the exact wording matters (a specific commitment, a sharp articulation of pain), not general color ### 3. Tag each item Apply a light, consistent taxonomy so items can be aggregated later: - **Product area** (pick from your existing taxonomy — don't invent new categories per call) - **Severity/urgency** (blocking / important / nice-to-have) - **Sentiment** (positive / neutral / negative) - **Confidence** (is this one customer's opinion, or did they say "everyone on our team" / "we hear this from our users too") ### 4. Check against what's already tracked Before writing this up as new, do a quick check: does this pain point or ask already exist in the backlog or in previous call summaries? If yes, this call is a **data point for an existing item**, not a new one — note it as reinforcement rather than creating a duplicate. This step is what makes accumulation actually work; skipping it is how backlogs end up with fifteen near-duplicate tickets. ### 5. Write the output Keep the write-up shorter than the transcript by an order of magnitude. Structure: ``` ## [Account/Call name] — [Date] **Context:** [1 line: who, call type, stage] **Pain points:** - [point] — [tag: area/severity] **Asks:** - [ask] — [tag: area/severity] — [new / reinforces existing #ticket] **Objections:** - [objection] **Competitive:** - [mention + context] **Buying signals:** - [signal] **Action items:** - [ ] [owner] — [item] — [due] **Notable quote:** "[≤ 1-2 short verbatims, only if precision matters]" ``` If this is going to a shared channel rather than a personal note, lead with a **one-line so-what** above the structure — the single most important thing from the call — because most readers will only see the first line. ## Quality bar / anti-patterns to avoid - Don't summarize sentiment ("customer seemed frustrated") without the specific pain point that caused it — sentiment without cause isn't actionable. - Don't let a single call's insight get treated as a trend. One call is a data point. Trends come from the triage/scoring step across many calls (see `feedback-triage-scoring`). - Don't paraphrase away specificity in asks — "wants better reporting" is nearly useless; "wants to export a filtered view to CSV, hit this twice in one call" is usable. - Don't skip the "already tracked?" check even when it's tempting to just ship the summary — this is the single highest-leverage step for keeping a backlog usable months later. ## Example **Input (excerpt):** A 30-minute renewal call with a mid-market account's ops lead, who mentions their team manually exports data every week because the built-in report doesn't support the filter they need, briefly mentions evaluating a competitor's reporting module "just to see options," and confirms budget is approved for renewal but wants the export issue addressed before their team lead signs off. **Output:** ``` ## Acme Logistics — Renewal call — 2026-08-14 **Context:** Ops lead, renewal stage, mid-market segment **Pain points:** - Manual weekly CSV export workaround because built-in report doesn't support their filter — [Reporting / Important] **Asks:** - Support saving/filtering custom report views for export — [Reporting / Important] — reinforces existing #REP-142 (4th mention this quarter) **Competitive:** - Mentioned evaluating a competitor's reporting module "to see options" — framed as exploratory, not active switching **Buying signals:** - Budget approved for renewal; team lead sign-off contingent on reporting fix **Action items:** - [ ] PM — confirm #REP-142 timeline — before next check-in (2026-08-28) **Notable quote:** "We're literally just doing this by hand every Monday." ``` Note the output ties directly back to an existing ticket rather than creating a new one, and the buying signal (sign-off contingent on the fix) is what actually makes this urgent — not the pain point alone.