Customer Case Studies: How to Run Them Without the Interview Call

Image URL

Do not index

AI summary

The guide explains how to run customer case studies without scheduling calls by using asynchronous interviews: pick suitable customers, send them six focused questions via email or a form, collect their written or voice answers, map responses into a structured case‑study template (headline, who, before, why you, what changed, numbers/proxies, quote), obtain written approvals, and then repurpose the finished study across sales assets rather than just a /customers page.

Title

Customer Case Studies: How to Run Them Without the Interview Call

Date

Description

A customer case study dies at the calendar, not the writing. How to pick, invite, collect async, write, and get approval — without booking a call.

Status

Done

Current Column

Published ✨

Person

Writer

You have a case studies page. Two stories. Both from last year.

You have eight names on a "to interview" list. Four of them said yes. None of them picked a time.

That is not a writing problem. It is a calendar problem.

A customer case study is a named person, a before, an after, and a number a stranger can check. Most programmes stall trying to book the interview that is supposed to produce those four things. This page is the rest of the system — pick, invite, collect, write, approve, use — without putting a Calendly link in the email.

If you want the short-form quote pipeline, start with the whole testimonial pipeline. This page is the long-form sales asset.

What a customer case study is (and is not)

A customer case study is a sales asset built from one customer's story. A prospect should be able to read the first six lines and know: who this is, what was broken, what changed, and whether the number is real.

It is not a testimonial. A testimonial is a sentence you can put next to a pricing button. What makes a testimonial good is specificity in a small space. A case study is the same job with a plot.

"Customer story" is the same artifact with a softer name. If your legal team will not let you say "case study", call it a story. The pieces do not change.

If there is no before, and no number you can defend (or an honest proxy when they cannot share one), it is a long testimonial. Publish it as a quote. Do not dress it up as a case study.

Why it dies at the calendar

I keep seeing the same pile-up. The writing is not the hard part. The hard part is getting two calendars to agree, then getting someone to show up, then getting someone to turn the transcript into a page.

The rest of the internet still treats the call as the method. As of August 2026, Salesforce's own guide tells you to interview the customer as a numbered step. Otter's starts after the conversation already exists — they sell the recorder, so that is the shape they write. I am not knocking either page. I am naming the assumption: the interview is a meeting.

Three ways that assumption kills the programme.

The yes that never books. They said yes in Slack. You sent three time slots. They meant to pick one. Two weeks later you are writing a follow-up that sounds like nagging, so you don't.

The call that moves twice and dies. Tuesday becomes Thursday. Thursday becomes "after the launch". After the launch they are tired, and the yes has gone cold.

The transcript nobody writes up. The call happened. You have 4,000 words of "um" and a story that was good in the room. Nobody owns the draft, so it sits.

The call is a coordination problem wearing a research costume. You do not need a meeting to ask six questions. You need answers.

Async is not a worse interview. It is the interview that actually finishes — they type or talk on a Thursday night, on their phone, without finding an hour that works for both of you.

Where async breaks. You cannot ask the third follow-up in the room. If they write "it saved us time" and stop, you do not get to lean in. You send one written follow-up, or you live with a thin answer.

I still book a call for two cases: the one flagship logo whose legal team wants a conversation, and the story that is a 40-minute mess you cannot flatten into six boxes. Not for the other seven names on the list.

Pick who

Not the happiest customer. The one a prospect can match.

Three filters, in order:

A recent win. They shipped something with you in the last few months. A 2023 story on a 2026 site reads as "nothing good has happened since".

A number they can share, or an honest proxy. Time, cost, volume, errors, a hire they did not make. If they cannot put a figure on it, they can still name the Tuesday that got shorter. That is publishable. "They loved us" is not.

They already talked. A support thread, a QBR, a tweet, a testimonial sitting in the inbox. You are asking them to confirm and extend something they already said, not to invent a narrative from a blank calendar invite.

Skip the Fortune 500 logo for the first ten. Their legal team will eat a quarter. Start with the customer who will reply in a week and whose company name a prospect in your ICP will recognise as "someone like us", not "someone we will never be".

If two names pass and one of them already wrote you a good testimonial, pick that one. The case study is the longer version of a sentence you already have.

The invite (no calendar link)

Do not send Calendly. A calendar link turns a yes into a meeting. Send the questions.

The social half of the ask — how well you know them, how not to make it weird — is how to ask for a testimonial. The wording below is just the vehicle.

Subject: six questions, no call — whenever you have twenty minutes

Hi [Name] —

[The specific moment: the launch, the ticket, the thing they said in Slack.]

Would you answer six questions I can turn into a customer case study?
No call. Type or talk, on your phone is fine. Skip any number you cannot share.

If you'd rather I draft from what you already told me and you edit, say so.
Either works.

[Link, or: just reply to this.]

— [Your name]

"I'll draft, you edit" is the escape hatch. Some people will not fill a form and will happily redline a paragraph. That still beats a cancelled Zoom.

Do not attach a 40-minute deck about "the case study process". You are asking for twenty minutes of answers, not onboarding them into a programme.

Collect without a call

Six questions. Each one is built to return a specific kind of sentence. If the pairing is "a mood", skip it.

The short-form four that produce a publishable testimonial live on questions to ask. These six are the long-form set. Do not send both.

1. Who are you, and what do you actually do day to day?

Designed to return: a name, a role, and a sentence a stranger can place. "[Name], marketing" is not enough. "[Name], the person who owns outbound at a 12-person agency" is.

2. What were you doing about [task] before [Product], and what was broken about it?

Designed to return: the before. Without it the rest is praise. Name the task for them or they will write "things were fine."

3. What almost stopped you picking us?

Designed to return: the objection a prospect is having right now. Put that sentence next to the pricing button.

4. What does [task] look like now, on a normal Tuesday?

Designed to return: a workflow, a number of tabs, a meeting that disappeared. Not "how has it helped."

5. What has it got you — and if you can put a number on it, do?

Designed to return: time, cost, volume, errors. If they cannot share a number, a named task that stopped happening is the honest substitute. Do not invent one for them, and do not write one in after.

6. Who should skip this?

Designed to return: the limitation. I would rather publish "skip this if you need [X]" than a third "highly recommend." Prospects already have enough of those.

If the answers are going on camera rather than into a form, use the same six as prompts, not a script to read. Our guide to video testimonials is the production half.

The manual path, if you want nothing from us. Paste the six into an email. Or a Google Form. Or a Notion page you share. That is enough. The answers are the asset. The tool is optional.

Where it breaks. Fifteen questions. You turned a favour into a survey. People who said yes to a case study did not say yes to homework. I would send six and stop. If one answer is thin, send that question back once, rewritten, not a new set of twelve.

Voice is worth offering. People say things out loud they will not type. A two-minute voice note on question 4 is often the whole story. You still have to trim it — they will not.

Write from the answers

Do not open a blank doc and "find the narrative". You already have the narrative. Map the answers onto seven slots:

Headline with an outcome. A number, or a named change, in one line. "How [Company] cut [task] from Fridays to a Tuesday morning." If you do not have a number, the named change is the headline. Do not invent a percentage to make it punchier.

Who. Name, role, company, size if they gave it. The reader is trying to self-identify in one glance.

Before. Question 2, almost verbatim. Clean the throat-clearing. Do not punch it up.

Why you. Question 3. The objection they got over.

What changed. Question 4. Tuesday, not "the platform".

The number, or the proxy. Question 5. If they skipped it, say so in the draft you send back — "you didn't share a figure; I used the Friday-to-Tuesday line instead. Change it if that's wrong."

The quote. Usually a sentence from 4 or 6. In their words. If you have tightened it, it goes back for approval.

If an answer is thin, one follow-up. Not a new call. "You said it saved time — can you say what that looks like on a Tuesday?" If they still shrug, cut that slot. A case study with six honest pieces beats seven with one you guessed.

Once the answers exist, building a case study with AI is a drafting accelerator. It is not a substitute for the answers. Feeding a model "write us a case study about Acme" and publishing the output is how you get a story nobody said.

The number

This is the part that makes people stall, and it is the part almost nobody writes about honestly.

Ask for it in the question, not in a later email after they have already done you a favour. Question 5 above is the ask. "If you can put a number on it, do" gives them permission to skip.

When they cannot share it — board rules, a pending fundraise, a customer who is also a competitor — do not invent a range. Do not write "approximately 3x" because it felt like 3x on the call you did not have.

Legitimate proxies, if they offer one:

A task that stopped (the Friday report, the weekly fire-drill)

A hire they did not make

A step that disappeared from the workflow

Time of day something now happens

A named proxy is stronger than a round percentage you cannot source. A stranger can picture Friday. They cannot audit "3x".

If they give you a number, attribute it. "According to [Name], [metric] went from [X] to [Y] in [timeframe]." If you measured it on your side, say that separately, and do not blend the two into one figure.

Approval

Get permission in writing. Be specific about where it will appear, because "can I use this on the site" and "can I put this in a paid ad" are different questions.

Ask separately for the name, the job title, the company, and the face. Plenty of people will give you the words and not the photo. A case study with a role and a company still works. One with a first name and "a SaaS company" barely does.

If anything changed hands — a discount, a free month, a gift card — the connection has to be disclosed. That is a legal requirement in several jurisdictions, not a nicety. The legal side of testimonials is the primer. Check your own jurisdiction rather than treating that page as advice.

Where this stage dies. The PDF sits in someone else's legal queue for six weeks, and the win is no longer recent. Send a short version first — headline, who, before, number, one quote — and offer the long page as a follow-up. A one-pager a counsel can clear in a day beats a twelve-page deck that never comes back.

If they will not let you name the company, you do not have a case study. You have an anecdote. I would not publish it as one.

Use it somewhere that is not /customers

Most case studies are published once, on a /customers page, and then never used again. That page gets the traffic a footer link gets.

A case study is a sales asset. Put the pieces where a deal is actually happening:

One objection, one paragraph. Question 3, next to the pricing button or the feature they hesitated on.

A pasteable block for a rep. Four lines: who, before, number, link. If a rep has to hunt the PDF, they will not send it.

A one-pager. Headline, snapshot, number, quote, CTA. For the email that goes out before a call.

The long page. For the person who is already convinced enough to go looking.

If the only place the story lives is /customers, you built a brochure.

Refresh it. A dated case study from a customer who has since churned is worse than none. Re-ask once a year: still true, still a customer, still the same title? If not, retire it. Do not accumulate.

Doing this with Testimonial

The six questions above work in an email. You do not need us for that.

What async case-study interviews change is the gap between "they said yes" and "you have answers". You build a question set — 5–10 questions, saved as a template — and send each customer their own link. No signup. They type, or they talk; voice is transcribed with ElevenLabs Scribe and dropped into the box as editable text. Answers arrive pre-attributed in the inbox. You can resend, remind, or revoke.

If someone scores 9 or 10 on an NPS survey, they can get the case-study invite automatically. That is a routing rule, not a new ask you have to remember.

Case Study is on Ultimate +. As of August 2026 that is $95/month/space, or $1,140 a year. Ultimate and Ultimate + are priced per space. The plans and pricing page is the live list.

Where it breaks, including for us. The builder will let you write ten questions. I have seen people write ten. Completion falls off because you turned a favour into homework. I would put six and stop. The product will not stop you.

Async still needs them to open the link. A reminder helps. It does not create time they do not have. And nothing in the tool clears legal for you — approval is still a human email.

If you have one customer, they will hop on a Zoom, and you are happy to write from a transcript, do the Zoom. The tool earns its place when the backlog is eight names and you cannot keep booking around them.

A separate free case study generator will draft from testimonials you already have. That is a writing aid, not an interview. Use it after question 5 has an answer.