case-study-writer

Case Study Writer

This skill produces customer stories that prospects believe. A good case study is about the customer, not the vendor: their situation, why they decided to change, how it went, and what is measurably different now. It also produces the shorter formats that sales teams actually use day to day.

When to use

• A customer has achieved a result worth sharing.
• Sales needs proof for a specific segment, use case or objection.
• Interview notes or a call recording exist but no story has been written.
• An existing case study reads like a press release and nobody uses it.

What you need

Ask for these first. If no interview has happened, start with the interview guide in step 1.

1. Customer context: industry, size, region, the team involved, and the roles of the people interviewed.
2. Interview material: notes, transcript or answers to the interview questions.
3. Results: metrics with a baseline and a time frame, plus qualitative outcomes.
4. Permission level: named with logo, named without logo, or anonymized ("a 400-person logistics company").
5. Target reader: the persona and segment this story should persuade.
6. Use cases: website, sales deck, outbound emails, proposals, social posts.

Process

1. Run or plan the interview. If needed, provide a guide that covers:
   • Before: what was happening, what it cost them, what they had tried.
   • Trigger: why they decided to act at that moment.
   • Evaluation: options considered, concerns, why they chose this solution.
   • Implementation: how it went, surprises, effort required.
   • Results: what changed, with numbers and a time frame; what colleagues noticed.
   • Advice: what they would tell a peer considering the same move. Ask for specific moments and quotes, not general satisfaction.
2. Find the story spine. Identify the single most compelling change, ideally tied to a business outcome (revenue, cost, time, risk). Everything in the story should support it.
3. Validate the numbers. Each metric needs a baseline, a result and a period ("from 6 weeks to 9 days over two quarters"). Mark any number that is an estimate. Avoid attributing all improvement to the product if other factors were involved; honest attribution increases credibility.
4. Choose the structure. A dependable outline: headline with the outcome, summary box (customer, challenge, solution, results), the situation, the decision, the implementation, the results, a closing quote, and what is next for the customer.
5. Write in the customer's voice where possible. Use direct quotes for the emotional and evaluative parts. Keep vendor descriptions short and focused on what the customer used, not a feature tour.
6. Handle objections inside the story. If the target reader worries about implementation effort or switching risk, show how this customer handled it.
7. De-identify properly when required. Replace names with descriptive labels, generalize or remove distinctive details (exact location, unique product names, specific dates, unusual figures), and assess how easily a knowledgeable reader such as a competitor or industry insider could still recognize the customer from the combination. De-identification lowers that risk but cannot guarantee it, so the customer approves the final anonymized version explicitly, just as they would a named one.
8. Create derivative formats. One-paragraph summary, a three-line proof snippet for emails, a slide (challenge, solution, results, quote), and two social post angles.
9. Prepare for approval. List the quotes and numbers the customer must approve, and flag anything sensitive.

Output format

Headline: [outcome-focused, specific]

At a glance
- Customer: [name or anonymized description]
- Challenge: [one line]
- Solution: [one line]
- Results: [2-3 bullet metrics with time frame]

The situation
[paragraph(s)]

The decision
[paragraph(s), why now, options considered]

Making it work
[paragraph(s), implementation and how risks were handled]

The results
[paragraph(s) with metrics and quotes]

"[closing quote]" [Name or role, company or description]

Short formats
- Summary paragraph: ...
- Email proof snippet (3 lines): ...
- Slide: Challenge / Solution / Results / Quote
- Social angles: 1) ... 2) ...

For customer approval: [list of quotes and figures]

Quality checklist

• The customer is the protagonist; vendor description is brief.
• Every metric has a baseline, result and time frame, or is labeled as an estimate.
• At least two direct quotes, attributed appropriately for the permission level.
• The "why now" and alternatives considered are included.
• Anonymized stories have had distinctive details generalized, their re-identification risk is assessed, and the customer has approved the final text.
• Short formats are consistent with the full story.
• Approval items are listed.

Common mistakes

• Vendor as hero. Stories that spend most words on product features read as ads and are less persuasive.
• Results without context. "Increased efficiency by 50 percent" means little without a baseline, a measure and a time frame.
• Smoothing over difficulty. A story with no challenges feels fabricated. A brief, honest hurdle builds trust.
• Generic quotes. "They are a great partner" proves nothing. Ask for quotes about specific changes.
• Weak anonymization. Removing the name but keeping a unique combination of city, size and niche identifies the customer anyway.
• Only the long version. Most proof is used in emails, slides and calls. Without short formats, the case study sits unused.

Example prompts

• "Here's the transcript of our call with a customer. Write a case study and email snippets."
• "Create an interview guide for a customer who cut onboarding time by half."
• "Anonymize this case study so the customer can't be identified, but keep it credible."
• "Turn this case study into a sales slide and two LinkedIn posts."
• "Our case studies read like press releases. Rewrite this one around the customer's story."