saurabhships 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:
- Recency/loudness bias — whoever spoke last, or most emotionally, dominates the summary, even if it wasn't the most important thing said.
- 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.