From a 45-Minute Recording to a Published Case Study in One Afternoon

Last spring a B2B SaaS client called and asked: "Can you take the recording from yesterday's call and turn it into a case study by Friday?" I said yes. The call was 45 minutes. The case study shipped in two days, and they used it for a year. The only part I didn't outsource was the judgment.

This is the workflow I now use for every case study. It's not magic. It's transcription, a structured extraction pass, a template, and a verification round. AI handles the busywork; the human part is what makes it sound like the customer instead of a brochure.

Why most "case studies" aren't case studies

Most B2B case studies that get published aren't case studies at all. They're product brochures with a customer logo in the corner. The reason: nobody sat down and asked the customer how it was before and what changed for them in a way that produced a quotable line. So the writer fills the gap with adjectives — "seamless," "powerful," "transformative." Those words mean nothing to a buyer.

A real case study answers four questions for a reader who is exactly like the customer:

1. Did you have the same problem I have?
2. What did you try before this?
3. What happened after you switched?
4. Can I quote someone specific?

If your draft can't answer those, it's not a case study. It's a product page.

Here's the five-step workflow I now run on every interview.

Step 1: Pre-interview prep — the questions that pull real quotes

Most interview guides are too long. Twenty questions, the customer gets tired by minute 15, and you get a transcript full of polite generalities. The interviews that produce the best case studies have six to eight questions, and three of them are blunt.

The blunt ones, in order:

1. "Walk me through the day you realized your old way wasn't working."
2. "What did you try before us, and why didn't it stick?"
3. "What was the moment you knew our thing was different?"
4. "What does your week look like now, compared to before?"
5. "What would you tell a peer who is still using the old way?"
6. "Anything you wish we'd done differently?"

The "day you realized" question is the one that produces the opening paragraph. The "moment you knew" question is the one that produces the pull quote. The "tell a peer" question is the one that produces the closing line.

Send these in advance. Ask the customer not to script their answers. You're not looking for polished — you're looking for specific.

Step 2: Transcription — don't be the one typing

Record the call. Use Otter, Notta, Fireflies, or just Zoom's built-in transcript. If you're on a tight budget, Whisper via the open-source whisper.cpp runs locally and is good enough for clean English audio.

Two practical notes:

• Tell the customer you're recording. In B2B they always say yes, but ask.
• Ask them to use a real microphone, not a laptop mic. Laptop-mic audio is where transcription errors live. A $30 lavalier mic on Amazon fixes about 80% of issues.

The transcript is your raw material. Don't try to write the case study straight from the audio — it's slower and you miss things.

Step 3: The extraction pass — let AI find the gold

This is where most people misuse AI. They paste the whole transcript in and say "write a case study." What they get is a generic-feeling article that uses the customer's words in the wrong places.

The trick is to extract first, then draft from the extracts. Here's the prompt I use, lightly edited per project:

You are an editor. I'll paste a customer interview transcript below.
Do NOT write the case study yet. Instead, return a structured table
with these columns:

| Quote (verbatim, with speaker tag) | Topic tag | Type |
| Type options: PAIN | OLD_WAY | DISCOVERY | DECISION | RESULT | METRIC | ADVICE |

Only include lines that are quotable or specific. Ignore filler,
pleasantries, and any sentence that doesn't give the reader a fact
or a feeling they can act on.

Why this works: forcing the model into a table forces it to commit. The "Type" column is the discipline. A line tagged PAIN belongs in the "before" section. A line tagged RESULT or METRIC belongs at the end. Anything untagged gets cut.

Push the customer for numbers in the follow-up email: "You mentioned 'a lot less time' — was that hours per week, per month? Any rough number you can put on it?" The best case studies have at least one specific number per section. If your customer can't give you one, you have a story, not a case study.

Step 4: The structure that works (and why I use the same one every time)

I've tried a dozen structures. The only one that consistently produces a publishable case study in a single draft is this:

1. Headline — name the customer, name the result. "How [Company] cut support response time from 14 hours to 22 minutes with [Product]."
2. The snapshot box — 3 to 5 bullets: company, industry, team size, the problem in one line, the result in one line.
3. The problem — 2 to 3 short paragraphs. Use the PAIN quotes. Get specific about cost, time, or risk.
4. The search — what they tried before, why it didn't work. This is the section most case studies skip, and it's the one buyers actually read.
5. The switch — what made them choose you. Use the DISCOVERY and DECISION quotes here.
6. The result — concrete outcomes, with at least one number. Use the RESULT and METRIC quotes.
7. The pull quote — one sentence, large, in the customer's voice. From the "moment you knew" answer.
8. The closer — "What would you tell a peer?" Use the ADVICE quote. End on the customer's words, not yours.

The structure isn't creative. That's the point. Creative structure is for essays. For case studies, the reader is scanning for the four questions from the top of this post. Every section above maps to one of them. Skip the cleverness.

Step 5: The draft — and why you should write it yourself

Counter-intuitive, given the topic: I write the case study draft by hand, using the extraction table as a reference, not the transcript directly. The transcript lies — it makes people sound more uncertain than they were. The table is curated.

Then I run a separate AI pass to do two things only:

1. Tighten the prose. Cut filler, shorten paragraphs to two to three sentences, kill any "in today's fast-paced world" type openings that crept in.
2. Match the voice. Paste a few paragraphs of the customer's own writing — a blog post, a tweet thread, a Slack message they sent you — alongside your draft, and ask: "Which sentences in my draft don't sound like this person? Rewrite them in the customer's voice, not the marketer's."

That second prompt is the one most people skip, and it's the difference between a case study that sounds like a brochure and one that sounds like a real person talking. Marketer voice is symmetrical — every sentence the same length, every paragraph ending on a noun. Customer voice has rhythm breaks, half-thoughts, and one-line asides. Protect those.

Step 6: Quote verification — the part AI cannot do

Every direct quote in the case study must go back to the customer for approval. Not because they'll reject it — most of the time they don't change a word — but because the moment you publish a quote they didn't sign off on, you've burned a relationship.

Email them the draft with the quotes in bold so they can't miss them. Add a note: "Please reply with any edits, or just 'looks good' if you're happy with them." Three sentences. Most customers reply within a day.

If a quote is critical to the case study, ask for a 5-minute call to walk through it. The first case study I ever published, the customer softened one phrase from "saved our bacon" to "made the difference for us" — and that softer line is the one that still gets used in sales decks six years later.

Step 7: Distribution — the half the team forgets

A case study that lives only on the website is a missed asset. The minimum distribution pass:

• A LinkedIn post from the customer's account, with a quote and a link.
• A LinkedIn post from your account, with a different quote.
• One email to your active prospects in the same industry (segmented, not blast).
• A snippet in the next newsletter.
• A slide in the next sales deck.

You don't need all of these. You need at least two. Most case studies get the website post and nothing else, which is why most case studies have no measurable impact on pipeline.

The mistake that breaks the whole workflow

If I had to name the one mistake that breaks this workflow, it's the temptation to write the case study before the customer signs off on the structure. The moment you commit to a structure, you start fitting quotes to it instead of the other way around. Hold off on the draft until you have the extraction table. The structure is downstream of the material, not the other way around.

What AI is actually good for here

To be precise about what the AI is doing and what I'm doing:

• AI: transcribe, extract, tighten, voice-match.
• Me: ask the blunt questions, decide which numbers to chase, write the first draft, send the quotes for approval, do the distribution.

Three of those five AI tasks are mechanical. The other two are judgment calls where AI is a useful second opinion, not the author. Keep that division clear in your head and you won't end up with a case study that sounds like every other one on the internet.

The whole process, end to end, is a 45-minute interview plus about three hours of focused work. The first time I did it, it took a week. The twentieth time, it took an afternoon. The difference was never the AI — it was knowing which parts to delegate and which to keep.