Synthesize customer interview transcripts into themes
Use case
Use this prompt after completing a round of customer interviews to transform raw transcripts into actionable insights. Synthesizing 5–10 interviews manually is time-consuming and prone to confirmation bias — this prompt structures the analysis systematically.
The prompt
You are a qualitative research analyst. Synthesize the following customer interview transcripts into a structured insights report. Research context: - Research question or objective:{{research_objective}}- Number of interviews:{{interview_count}}- Interviewee profiles:{{interviewee_profiles}}- Interview transcripts or notes:{{interview_content}}- Hypotheses being tested:{{hypotheses}}Synthesize the interviews into a structured report with these sections: ## 1. Research Summary (2–3 sentences) Who was interviewed, what was explored, and the one-line headline finding. ## 2. Key Themes (4–6 themes) For each theme: - Theme name (clear and specific — not "customer satisfaction" but "setup complexity creates first-week abandonment risk") - Description: what this theme means in plain language (2–3 sentences) - Evidence: which interviewees mentioned it and how (quote at least one verbatim or near-verbatim line) - Frequency: how many of the{{interview_count}}interviews contained this theme - Implication: what this means for product, marketing, or customer success ## 3. Hypothesis Validation For each hypothesis listed: Validated / Invalidated / Partially validated / Inconclusive — with a 1–2 sentence explanation drawing on the interview evidence. ## 4. Notable Quotes 5–8 direct quotes that are particularly powerful, specific, or representative. Label each with interviewee role/company type (anonymized if needed). ## 5. What We Didn't Expect 1–2 surprising findings that weren't anticipated in the research design. ## 6. Recommended Actions 3–5 specific, prioritized recommendations based on the findings — with suggested owners (product, marketing, CS, support). ## 7. Research Gaps What questions weren't answered by this round? What would a follow-up round investigate?
Variables
{{{{research_objective}}}}Replace with your {{research objective}}{{{{interview_count}}}}Replace with your {{interview count}}{{{{interviewee_profiles}}}}Replace with your {{interviewee profiles}}{{{{interview_content}}}}Replace with your {{interview content}}{{{{hypotheses}}}}Replace with your {{hypotheses}}
Example
Input
research_objective: understand what triggers ops leaders to evaluate BI tools and what makes them choose one over another interview_count: 6 interviewee_profiles: 6 operations directors/VPs at mid-market companies (100–400 employees); 2 logistics, 2 retail, 2 professional services; all evaluated a BI tool in the last 18 months hypotheses: | 1. Trigger for evaluation is usually a specific failure event, not proactive improvement 2. Ease of setup without IT is most important evaluation criterion 3. Most tools fail in implementation, not evaluation interview_content: | [Abbreviated for example — in practice, paste full transcripts or dense notes] Interview 1 (logistics, VP Ops): "We didn't start looking until we had a major shipping error that cost us a client. Before that, I knew the reporting was bad but it wasn't urgent enough to change." Interview 2 (retail, Dir Ops): "The trigger was our COO joining. She wanted real-time data in her first week and what we had was embarrassing. That's when I started the evaluation." Interview 3 (professional services, VP Ops): "We actually had been planning to improve reporting for a while. It was more of a proactive thing for us — we were scaling and I knew the spreadsheet system would break." Interview 4 (logistics, Dir Ops): "We tried Tableau. The implementation took 6 months and we never got past the first dashboard because IT kept deprioritizing our requests." Interview 5 (retail, VP Ops): "The demo always looks amazing. The reality is that connecting your actual data takes weeks or months, not days." Interview 6 (professional services, Dir Ops): "I evaluated 4 tools. The winner was the one that didn't need IT to set up. That was the main filter."
Output
## 1. Research Summary Six operations leaders across logistics, retail, and professional services were interviewed about their BI tool evaluation journeys. The headline finding: the decision to evaluate is usually reactive (triggered by a specific event), but the decision to buy is dominated by one factor — whether implementation requires IT involvement. ## 2. Key Themes **Theme 1: A Specific Event Triggers Evaluation (not proactive improvement)** Description: For 4 of 6 interviewees, the decision to evaluate a BI tool was triggered by a specific failure event or change — a client loss, a new executive demanding better data, a visible embarrassment. Only 2 described proactive evaluation. Evidence: "We didn't start looking until we had a major shipping error that cost us a client." (Interview 1) / "The trigger was our COO joining — she wanted real-time data in her first week and what we had was embarrassing." (Interview 2) Frequency: 4 of 6 interviews Implication for marketing: Demand generation campaigns should target "the moment after the failure," not the ongoing status quo. Content about "signs you've outgrown your reporting process" may land better than "the benefits of BI." **Theme 2: IT Dependency Is the Primary Evaluation Filter** Description: When asked what made them choose one tool over another, 5 of 6 interviewees named IT involvement (or its absence) as the deciding factor. Evidence: "The winner was the one that didn't need IT to set up. That was the main filter." (Interview 6) Frequency: 5 of 6 interviews Implication for product: "No IT required" should be the lead claim in all messaging — not a supporting feature. **Theme 3: Implementation Is Where Tools Fail** Description: Multiple interviewees described evaluation experiences that went well (good demos) but implementations that failed due to IT deprioritization, data connectivity issues, or team capacity. Evidence: "Tableau took 6 months and we never got past the first dashboard because IT kept deprioritizing." (Interview 4) / "The demo always looks amazing. The reality is that connecting your data takes weeks or months." (Interview 5) Frequency: 3 of 6 interviews (and 2 more mentioned "fear of implementation" even without personal experience) Implication for sales/CS: Implementation risk is a common objection. Having a specific "time to first dashboard" metric and an onboarding story is critical to competitive differentiation. ## 3. Hypothesis Validation - H1 (failure event triggers evaluation): **Validated** — 4 of 6 interviews confirm. Caveat: scaling-related proactive evaluation exists as a secondary trigger. - H2 (ease of setup is most important criterion): **Validated** — 5 of 6 named IT independence as the primary filter. - H3 (tools fail in implementation not evaluation): **Validated** — 3 personal experiences confirmed; 2 more expressed this as a fear. ## 4. Notable Quotes - "I knew the reporting was bad but it wasn't urgent enough to change — until the shipping error." (Logistics VP) - "The demo always looks amazing. The reality is that connecting your actual data takes weeks or months, not days." - "The winner was the one that didn't need IT to set up. That was the main filter." - "Before the new COO arrived, bad data was everyone's problem. Suddenly it was my problem." ## 5. What We Didn't Expect - The role of executive arrivals as a trigger: 2 of 6 interviewees attributed their evaluation to a new senior leader demanding better data. This "executive arrival" trigger wasn't in our hypothesis set and may represent a targetable audience signal. ## 6. Recommended Actions 1. **Marketing (owner: content team):** Develop content targeting the "moment after the failure" — case studies framed as "we had a data crisis and here's what we did" resonate with the reactive trigger pattern. Priority: High. 2. **Product marketing (owner: PMM):** Make "no IT required" and "time to first dashboard" the lead claims in all competitive materials. Priority: High. 3. **Sales (owner: enablement):** Build an implementation risk objection guide — specifically addressing the "we tried Tableau and it took 6 months" comparison. Priority: Medium. ## 7. Research Gaps - We don't yet understand the buying committee dynamic: who else is involved in the final purchase decision beyond the ops leader? - We didn't interview anyone who evaluated and chose NOT to buy a BI tool. This "status quo" perspective would be valuable for understanding non-buyers.
Tips for best results
- 1Paste full transcripts rather than notes — Claude extracts more nuanced patterns from raw language than from pre-summarized notes.
- 2Run 5–8 interviews before synthesizing. Fewer than 5 produces patterns that may be coincidence; more than 10 usually reveals diminishing returns on new themes.
- 3The 'What We Didn't Expect' section is often the most valuable for product and marketing teams — it surfaces blind spots that wouldn't appear in a hypothesis-driven analysis.
- 4Share the notable quotes directly with your marketing team — these verbatim customer expressions are more powerful than any copy your team can write.
- 5After synthesis, run the results by 2–3 of the interviewees and ask: 'Does this ring true to you?' Validation from participants builds credibility of the findings internally.
Related prompts
Write a customer discovery interview discussion guide
intermediateGenerate a structured discussion guide for a customer discovery interview, with questions designed to surface real behavior, motivations, and unmet needs.
Write a churn exit interview guide
intermediateGenerate a structured exit interview discussion guide for customers who have cancelled or are churning, designed to surface honest root causes.
Identify jobs-to-be-done from customer interview notes
advancedAnalyze customer interview notes to identify the jobs-to-be-done (JTBD) customers are hiring your product to do — and the functional, emotional, and social dimensions of each job.
Need help implementing this prompt in your workflow?
Book a call