Turn 5 Customer Interview Transcripts Into 12 Case Study Angles (The NotebookLM Three-Notebook Workflow)

Five interviews, twelve case-study angles, four hours of work. None of them a stitched-together Frankenstein. Each one reads like a real customer wrote it. Here's the three-notebook NotebookLM setup that makes that possible.

Why five interviews usually become one case study

Most B2B teams treat each interview as an island. Open the transcript, highlight the good lines, draft, ship, move on. By the time that one case study is published, you've forgotten the line in interview #3 that would have been a better opening for the #4 draft. The "extra" insights from #2 get cut — not because they weren't useful, but because they don't fit the story you already committed to. One interview, one case study. That's the default. It's a waste of transcripts.

The other failure mode is uglier: dump all five transcripts into a single AI prompt and ask for "a case study." You get a smoothie. The model averages the five voices, picks the most prominent themes, and produces a case study that sounds like no one in particular. It looks done. It is not usable.

Both problems come from doing the work in one pass instead of three.

The three-notebook split — why it isn't over-engineering

Before you upload anything, decide on the structure. The setup is:

• Notebook 1 — extraction: one notebook per interview, with a structured prompt that returns a tagged table of quotable lines.
• Notebook 2 — synthesis: a single notebook containing the five extraction tables, with a prompt that returns themes, a dozen angles, and the angles you shouldn't write.
• Notebook 3 — writing: a clean notebook for each case study you actually ship, with the chosen customer's extraction table plus a sample of their natural writing voice.

Three notebooks because each one has a different job. Notebook 1 protects the customer's voice from being blended with anyone else's. Notebook 2 forces pattern-finding across the batch, not within a single conversation. Notebook 3 is a clean writing room that doesn't get contaminated by the analysis pass.

If you try to do this in one notebook, the model sees the cross-interview pattern data while drafting, and the resulting case study picks up the averaged voice of all five customers. That's the case study that sounds like a brochure. Splitting the notebooks forces the model to write to one customer's voice in step 3, which is the whole game.

Notebook 1: extract from each interview

Open one notebook per interview. Upload the transcript (text file, Google Doc, or PDF — all three work). In the Configure Notes panel, paste this as the system prompt:

You are an editor working on a B2B case study. I will paste one
customer interview transcript at a time. Do NOT write the case study.

Return a structured table with these columns:

| Verbatim quote (with timestamp) | Tag | Section | Strength |
| Tag options: PAIN, OLD_WAY, DISCOVERY, DECISION, RESULT, METRIC, ADVICE |
| Section options: opening, before, switch, result, closer |
| Strength: strong / moderate / weak |

Rules:
- Only include lines that are quotable or specific.
- Preserve the speaker's exact words, including hedges and half-thoughts.
- Flag at least 3 lines as "strong" — these are pull-quote candidates.
- If the customer gave a number, capture it verbatim.
- If a line could fit two tags, pick the one that fits the
  case-study arc, not the one that sounds clever.
- Ignore pleasantries, scheduling talk, and any sentence that does
  not give the reader a fact or a feeling they can act on.

Run it. You'll get a 30–50 line table per interview. Repeat for all five.

What this prompt does that "summarize this interview" doesn't: it forces commitment. A line tagged PAIN belongs in the "before" section. A line tagged RESULT belongs in the result. Anything untagged gets cut from the draft. The model is forced to choose, not hedge.

The "preserve hedges and half-thoughts" rule is the one that matters most for voice. A customer saying "I mean, it wasn't broken, but it was… kind of a lot" reads more human than the cleaned-up "it was inefficient." The first version is what a buyer trusts.

Notebook 2: synthesize across all five

Create a second notebook. Upload the five extraction tables (paste them as text sources — works fine, no formatting needed). Prompt:

You are a content strategist. I am uploading extraction tables from
5 customer interviews (same schema, same tags). Do NOT write case
studies yet.

Return three things:

1. A pattern table — themes that appear in 3+ interviews, with the
   representative quote from each interview. Quote count per theme
   matters; a theme mentioned by 4 of 5 customers is stronger
   than one mentioned by 3 of 5.

2. Twelve distinct case-study angles. For each:
   - A one-line hook (the result, not the feature)
   - Which 2–3 interviews best support it
   - Which "section" tags dominate (e.g., mostly PAIN + RESULT
     = a "before-and-after" angle; mostly DISCOVERY + DECISION
     = a "switch" angle)
   - A likely audience (heads of marketing / ops / RevOps / etc.)

3. The 3 angles that would make the worst case studies, and why.
   Be specific. "Generic" is not an answer.

Twelve is not a magic number. It is high enough that the model has to dig for the long tail, low enough that it can't pad with filler. From those twelve, pick the four or five that match the next quarter's campaign goals. The rest sit in a content bank for later use.

Item 3 — the "what not to write" list — is what most teams skip, and it's the one that prevents the failure mode where you ship twelve generic case studies about "efficiency gains." If the model tells you the "AI saved us 10 hours a week" angle is weak, listen. It's weak because every competitor is writing that angle.

Notebook 3: write the case study, protect the voice

Create a third notebook for each case study you actually ship. Upload two things:

1. The extraction table for the chosen customer
2. A voice sample — three to five paragraphs of the customer's own writing: a tweet thread, a Slack message they sent you, a blog post, a public LinkedIn post. If they have no public writing, use their "what would you tell a peer" answer from the interview. It is the closest to their casual voice you will get.

Then prompt:

You are a B2B case-study writer. Two sources are attached:
(1) the extraction table for this customer
(2) a voice sample of the customer.

Write a 600-word case study using this eight-section structure:
headline, snapshot box, problem, search, switch, result,
pull quote, closer.

Hard rules:
- Use the customer's exact phrasing for all direct quotes.
- Match the rhythm of the voice sample — short sentences,
  half-thoughts, one-line asides. Do NOT match marketer cadence
  (uniform sentence length, paragraphs ending on nouns).
- Replace marketing adjectives (seamless, powerful, transformative)
  with specific facts from the interview.
- The pull quote must come verbatim from the "moment you knew" answer.
- The closer must be the customer's words, paraphrased only if it
  improves clarity.
- If the customer's voice sample does not support a section, write
  that section in 1 sentence and move on. Do not pad.

Run it. You'll get a draft in 90 seconds. Edit the first paragraph by hand — that's the one that needs to land. The rest usually needs tightening, not rewriting.

The voice sample is the difference between a case study that gets republished in the customer's LinkedIn and one they quietly don't share. If you skip the voice upload, the model defaults to "LinkedIn-formal B2B prose," which is what every other vendor's case study already sounds like.

The mistake that breaks this workflow

Uploading raw transcripts straight into notebook 1 and skipping the extraction prompt. The result is a "summary" of each interview that loses the half-sentences and hedges — the parts that make the customer sound human. Without the table, notebook 2's "12 angles" come from whatever the model thinks is most prominent, not from what's actually quotable. Keep the extraction step. It looks redundant. It isn't.

The other common mistake: using the same notebook for synthesis and writing because "it's all the same data." The cross-interview pattern data is contaminating when you are trying to write a single case study. It is the noise that produces the averaged-voice case study. Keep them apart.

What a sprint looks like in practice

Last quarter, my team ran this on a six-customer batch in a three-day sprint. Five extraction notebooks per customer, one synthesis notebook, one writing notebook per shipped case study. Final count: four published case studies, seven more angles banked for the next campaign, and zero generic-sounding prose. The customer who reads her own case study says, "yep, that's how I'd say it." That is the bar.

The whole pipeline, end to end, is roughly four hours per five-customer batch after the interviews are recorded. The first time we did it, it took a full week because we kept re-running notebook 2 with the wrong instructions. The third batch, we hit the four-hour mark. The difference was never the tool — it was having prompts that force commitment, not hedging.

If you have a stack of transcripts you've been "meaning to turn into case studies" sitting in a folder somewhere, this is the weekend project. Five notebooks, three prompts, four hours. The angle you'd have missed in interview #3 is the one that ships.