AI prompts for writing case studies work when the model drafts only from material you collected from the real customer (their problem in their words, before-and-after numbers, quotes they approved) and is told explicitly not to invent anything. The useful workflow has four steps: prepare the customer interview, turn the transcript into a fact sheet, draft the case study from that fact sheet, and then cut it into shorter assets for sales. This guide gives a prompt for each step, a worked example, and the review and approval checks a published customer story needs.
Why AI case studies go wrong
A customer case study is a short account of how a real customer had a problem, what they did about it with your product or service, and what changed. Its value as sales evidence depends entirely on being true and specific. That is where a language model is weakest: asked to “write a case study about how Acme used our software”, it will produce fluent, plausible text full of numbers and quotes that nobody said.
Invented details are not only embarrassing. In the US, a case study used in marketing is advertising, and the FTC’s guidance on endorsements and testimonials says an endorsement must reflect the endorser’s honest opinion, that edits which change a customer’s meaning are misleading even when they only shorten a quote, and that exceptional results need context about what people can generally expect. The workflow below is designed so the model never has room to invent.
Step 1: Prepare the customer interview
The interview is the raw material, and better questions produce a better story than any drafting prompt. Use AI here to prepare questions tailored to this customer, not to replace the conversation.
<customer>
Company: [name, industry, size]
Contact: [name, role]
What they bought: [product/plan, since when]
What we already know: [notes from sales and account management, support history,
any usage data we can share with their permission]
</customer>
Write an interview guide for a 30-minute case study call with this customer.
Sections:
1. Before: what they were doing before, what it cost them (time, money, risk),
what triggered the search for something new.
2. Decision: what alternatives they considered and why they chose us.
3. Implementation: what it took, what surprised them, what went wrong.
4. Results: what changed, with follow-up questions that ask for numbers,
comparisons and examples ("how did you measure that?", "compared to what?").
5. Advice: what they would tell a peer considering the same move.
Rules:
- Open questions, one idea per question, no leading questions that assume a
positive answer.
- For each results question, add a follow-up that asks how they know.
- Mark 3 questions as essential if the call runs short.Why each part is there: the “compared to what?” follow-ups are what turn “it saves us lots of time” into “month-end close went from five days to three”, which is the difference between praise and evidence. Asking what went wrong produces honest detail that makes the story more credible, and it often yields the best quote. Record the call (with permission) and get a transcript.
Step 2: Turn the transcript into a fact sheet
Separating extraction from writing is the most effective way to stop invented details. The model first pulls out only what the customer said, with references back to the transcript, and you check that list before any prose exists. This is a form of prompt chaining: each step’s output is small enough to verify.
<transcript>
[paste the interview transcript]
</transcript>
Extract a case study fact sheet from the transcript. Use only what the customer said.
Output these sections:
- BEFORE: the situation and its cost, in bullet points.
- TRIGGER: why they started looking.
- ALTERNATIVES: options they considered and why they were rejected.
- IMPLEMENTATION: steps, timeline, problems.
- RESULTS: each result as "metric | before | after | how they measured it".
If the customer gave no number, write the qualitative change and mark it QUALITATIVE.
- QUOTES: up to 8 candidate quotes, copied word for word, each with its timestamp.
- GAPS: important questions the transcript does not answer.
For every bullet, add the transcript timestamp it came from.
Do not round, combine or estimate numbers.The transcript sits inside its own tags so the model can tell your instructions from the customer’s words; Anthropic’s prompting guidance recommends descriptive XML tags for exactly this kind of mixed prompt. The timestamps make checking fast: you can jump to the moment in the recording and confirm each fact. The GAPS section becomes your follow-up email to the customer. If you want stricter source-tracing, the prompt in making Claude cite the exact sentence behind every claim applies directly to transcripts.
Step 3: Draft the case study from the fact sheet
Once the fact sheet is verified, the drafting prompt can focus on structure and readability, because the facts are fixed.
<fact_sheet>
[paste the verified fact sheet]
</fact_sheet>
<audience>
Who will read this: [e.g. operations leads at mid-size logistics firms]
Their main objection to buying: [e.g. "migration will disrupt operations"]
</audience>
Write a customer case study of 500-800 words using only facts in <fact_sheet>.
Structure:
1. Headline: lead with the most specific verified result.
2. Summary box: customer, industry, challenge, result, in 4 short lines.
3. The challenge: the before situation and why it mattered, in the customer's terms.
4. Why they chose [our company]: from ALTERNATIVES, stated fairly.
5. Implementation: include at least one difficulty and how it was handled.
Address the audience's main objection here if the facts allow.
6. Results: use RESULTS exactly. Present QUALITATIVE items as qualitative.
7. One pull quote, chosen from QUOTES, copied exactly.
Rules:
- Do not add any number, name, date, quote or claim that is not in <fact_sheet>.
- Replace adjectives like "amazing" or "seamless" with the specific fact behind them,
or delete them.
- Use subheadings so a reader can skim.
After the draft, list every factual statement with the fact-sheet line it came from.Why the structure looks like this: problem, solution and result is the classic case study shape, but buyers read case studies to answer a doubt, so the prompt includes their main objection and places the answer in the implementation section, where it is most believable. The closing list of statements and their sources is a self-audit you can scan in a minute. Length is a guide, not a rule; a short web story and a detailed PDF for technical buyers can both work.
Step 4: Cut it into sales assets
A finished case study gets more use when it is broken into formats the sales team can drop into conversations. Each derivative should add nothing beyond the approved case study.
<case_study>
[paste the approved case study]
</case_study>
Create these assets using only claims stated in <case_study>:
A. One-page sales summary: customer, two-sentence problem, headline result,
3 bullets a rep can paraphrase on a call.
B. Email snippet: 2-3 sentences a rep can paste into a follow-up, ending with a
link placeholder [LINK].
C. Proof line: one sentence under 25 words for a landing page or proposal.
D. Social post: under 80 words, tagging placeholder [@customer], no hashtags.
E. Objection card: the objection this story answers, and the 2-sentence answer.
Do not add any claim that is not explicitly in <case_study>.The proof line and email snippet are the pieces reps use most. They fit naturally into sales proposals and into the proof section of landing page copy.
Worked example: from transcript line to published sentence
The following example is invented to show how a fact moves through the pipeline. The customer, a 40-person freight brokerage called “Northline”, and all figures are illustrative.
| Stage | What it looks like |
|---|---|
| Transcript (12:40) | “Honestly, before, rate confirmations were all email. Two people spent most of Monday chasing them. Now it’s maybe an hour, and that’s mostly exceptions.” |
| Fact sheet | RESULTS: Monday rate-confirmation work | 2 people, most of the day | about 1 hour, mainly exceptions | customer’s estimate, not measured (12:40) |
| Weak draft (generic prompt) | “Northline cut admin time by 85% and transformed its operations.” |
| Draft from fact sheet | “Before, two people spent most of each Monday chasing rate confirmations by email. Now the job takes about an hour, mostly handling exceptions, according to Northline’s operations lead.” |
The generic draft invented a percentage the customer never gave. The fact-sheet version keeps the customer’s own estimate, says it is an estimate, and still reads as a strong result. If you later want a percentage, ask the customer for measured figures and get them approved.
Review and approval checklist
Before a case study is published, it needs a fact check, a legal-style check and the customer’s sign-off. Use this list:
- Every number traces to the fact sheet, and every fact-sheet number traces to the transcript or a document the customer provided.
- Quotes are verbatim. Light trimming is fine only if the meaning is unchanged; the FTC guidance treats meaning-changing edits as misleading.
- Exceptional results have context. If this customer’s result is better than what most customers see, say what is typical or frame it clearly as one customer’s experience, in line with the FTC’s guidance on typical results.
- Material connections are disclosed if the customer received something for participating that readers would not expect, such as a discount or payment. The FTC compliance checklist for AI testimonials and reviews covers when disclosure is required.
- The customer approves the final text, including every quote attributed to a named person, and confirms that data about their business can be shared. Get this in writing.
- Confidential details are removed: internal system names, prices they paid, partner names they have not cleared.
- No AI-generated images of the customer’s people or premises presented as real.
An AI review prompt can do the first pass on items 1 to 3:
Compare <case_study> with <fact_sheet> and <transcript>.
List: (1) any statement not supported by the fact sheet; (2) any quote that differs
from the transcript, showing both versions; (3) any result presented as typical or
general when it is one customer's experience. Quote each problem exactly.When you have no customer interview
Sometimes a customer agrees to a story but will not do a call. You can still work from written sources: a short questionnaire built from the Step 1 guide, support tickets, onboarding notes, and usage data they agree to share. Feed those into the Step 2 prompt instead of a transcript, with document names in place of timestamps. What you should not do is let the model fill gaps with plausible results. If there is no measurable outcome, describe the qualitative change honestly; an accurate “the team stopped using spreadsheets for scheduling” persuades more than an invented percentage that a prospect may later ask about.
Case studies also feed other sales work. The patterns across several stories are good input for a win-loss analysis, and the alternatives customers considered tell you which competitors to prepare for.
