How to write a case study customers will let you ship

TL;DR. A case study is one short story about one customer’s specific outcome, structured the same way every time: customer, situation, the question, what they did, the numbers, the quotes, and what’s next. Two interviews — one to draft, one to verify — a clear owner, a legal-and-customer approval lane that doesn’t take a quarter, and a doc that lives in a wiki everyone can find. Three pages. Two named numbers per page. Refreshed when the customer’s reality changes; archived when it doesn’t.

Most case studies read like a press release that lost an argument with a brochure. (Whiskers, our PM, calls them “OKRs in costume — same vibe, fewer verbs.” He’s right enough that we left it in.) The good news about how to write a case study is that the shape has been the same since the day Adobe shipped the first PDF you didn’t read all of: customer, problem, solution, result. The bad news is that the part that actually matters — the interview, the approval workflow, the cross-functional ownership, and the doc-not-PDF question of where the case study lives between launches — is the part the long-form SERP guides skip in favour of eight steps to a compelling story. The rest of this post is the working shape, the interview the case study is downstream of, and the boring operational decisions that turn a customer story into a publishable artifact instead of a quarter-long stall.

A case study is one short story about one customer’s specific outcome

A case study is a written customer-story artifact — not a testimonial, not a logo on a slide, not a webinar transcript — that documents one customer’s specific situation, what they did, and what changed for them. The shape is from the same family as academic case writing (the one situation, examined deeply template) but the audience is different: a prospective customer who is asking “someone like me — did this work?” The case study is the receipt.

A case study succeeds when:

A reader who matches the customer’s shape can read it cold, recognise their own problem in the first paragraph, and finish with a clear sense of what they’d be signing up for.
The numbers are real, attributed, and would survive a sales-call follow-up question.
The customer would forward it to a peer without an apology.
The doc is short enough to read in five minutes and concrete enough that the reader could repeat the customer’s path.

Anything shorter is a quote on a homepage; anything longer is a white paper. Two to four pages is the working range. A case study that takes ten minutes to read is a case study that gets opened once and bookmarked into oblivion.

Case study vs customer quote — scope is the difference

The two artifacts get confused and shouldn’t. The split that survives contact with a real customer-marketing programme:

Artifact	Scope	Where it lives	Length
Customer quote	One short attributed sentence on one outcome	Homepage, social tile, sales deck slide	1–3 sentences
Case study	One full short story about one customer’s situation, decisions, and results	Customer-stories page, sales-call follow-up, PDF download	800–2,000 words

A quote is “We cut onboarding time from two weeks to two days with Raccoon Page.” — Anna, Head of Engineering, Some Co. A case study is “Here’s how Some Co’s three-person platform team moved from a Confluence space nobody could find to a wiki their on-call could reach in one keystroke; here’s the migration, here are the numbers a quarter later, here’s what they’d do differently.”

If you’re writing one and reaching for the other’s content, you’re writing the wrong artifact. Two outputs. Same source interview. A good interview produces both — a quote you can pull into a landing page tile, and a case study you can attach to a deal.

The seven sections every case study needs

A working case study is a single short doc with seven sections, in this order. Same headings every time; the reader doesn’t have to learn a new format per customer.

Section	What it answers	Length
The customer	Who they are, what they do, how big	1 paragraph + a fact-row
The situation	What their world looked like before	1–2 paragraphs
The question	The specific problem they were buying for	1 paragraph
What they did	The decisions, the rollout, the people	A third of the doc
The numbers	Before / after, attributed, dated	A table + a paragraph
Quotes	Two or three named, in voice	Interspersed or grouped
What’s next	Where they’re going from here	1 paragraph

The Customer row is the reader’s first comparison check — “is this me?” — and it earns its keep with a fact-row, not a mission statement. “Some Co. 14 engineers across three time zones. Bootstrapped, B2B SaaS, two-year-old company. Moved from Confluence to Raccoon Page in March 2026.” Anything else is the about page; the case study needs the shape that lets a stranger sort “like me / not like me” in seven seconds.

The Situation row is “what hurt enough to start looking.” Not the entire backstory — the specific pain that made the customer open a tab and search. “Search across the wiki was slower than asking the engineer who wrote the doc. Half the team had stopped using it.” That’s a situation; “they wanted a modern collaboration platform” is a brochure.

The Numbers row is the load-bearing one. Before / after, each attributed. “P50 page load time: 1.4s → 80ms. Pages opened per engineer per week: 4 → 22. Time to find a runbook: 90s → 6s. Numbers via internal analytics, May 2026.” If the customer won’t let you publish the numbers, the case study is a testimonial in a fancy outfit; honest case studies need the math. (Help Scout’s customer-stories hub is the best public reference for what “numbers attributed, dated” looks like at scale.)

The Quotes row is two or three. Not eight. A case study with nine pull-quotes is a case study that didn’t have a story.

The interview questions that produce a publishable case study

The case study is downstream of the interview, and the interview is downstream of the prep. The single biggest predictor of a publishable case study is asking the right questions in the right order.

A working interview script, in order:

“Walk me through what you were doing before you started looking.” — Opens the situation. Listen for the moment they decided the status quo wasn’t acceptable.
“What was the specific thing that pushed you to look for a different tool?” — Pins the question the case study answers. If they can’t name it, the case study probably isn’t a case study.
“How did you evaluate? What was on your shortlist?” — Honest evaluation context. Other tools may get named; that’s fine for a draft (you’ll cut or anonymise per legal review).
“Walk me through the first thirty days after you switched.” — The what they did row. Concrete actions, dates, surprises.
“What changed for the team? Numbers if you have them; vibe if not.” — Opens the numbers row. Push, gently, for two real measurements. Be willing to publish one if that’s all you get.
“What was harder than you expected?” — The honesty question. Case studies that include one what we’d do differently moment read three times more credibly than the ones that don’t.
“What would you tell a peer at another company who’s where you were six months ago?” — Produces the headline quote. This is your pull-quote candidate; tag it.

Two practical interview rules that survive every customer:

Record the call. With consent. Transcribe immediately. The case study writes itself from a transcript and fights you to the death from a memory.
One interview is not enough. Two: one to draft, one to verify. The second call is shorter (30 minutes), targeted at the gaps in the draft, and produces the quotes you couldn’t get cold in the first call.

For an interview template you can copy into your wiki and adapt per customer, the Case Study template is the importable shape — opens with the seven-section scaffold, includes the interview prompts, leaves the numbers row blank.

Who owns the case study inside the org

This is the part the long-form SERP guides skip. The eight-step guides explain what to write; the twelve-step guides explain what to include; almost none of them name who, inside the company, is on the hook for the case study from pitch to publish. The result is a cross-functional artifact owned by nobody, which is why your last three customer stories are seventy percent drafted and a quarter old.

The working pattern, after watching teams stall and unstall:

One named owner per case study. Not a team alias. Product marketing usually wins this — they have the publishing surface — but the owner can be customer success or sales-enablement at smaller companies. The rule is named, not which department.
A clear approval lane. Customer review → internal review (legal + sales + the account team) → customer final → ship. Named reviewers, named days. Most case studies stall on legal and customer-final; the lane is what protects against both.
An SLA on each step. “Customer first review: five business days. Legal: three. Customer final: five. If anyone exceeds the SLA, the owner re-routes.” The case study a customer signed off on in October that ships in March is a case study that should have shipped in November or not at all.
The handoff out of sales is not the start. Sales hands the customer to the case-study owner after the customer has explicitly opted in to a story. The opt-in question belongs in the QBR or in the renewal kickoff, not in the case-study request email itself.
The interview is owned by the writer. Not by the AE. Not by the CSM. The writer who’s drafting the doc runs the call — they hear the cadence, they catch the tangent that becomes the headline.

The pattern this post stands behind: the best case study you’ll ever write is the one your customer-success team has already half-written. CS has the interview notes from the QBR; product marketing has the publishing surface; the case study is the artifact that turns the CS notes into something the prospect can read. Read CS’s notes first; write the second draft yourself; let CS verify the third.

Where the case study lives between launches

The standard answer is “as a PDF on the customer stories page,” and it’s wrong in the same way that “runbooks live in Google Docs” is wrong: the PDF is the export, not the home. Once the case study is a PDF, every update is a re-export, every broken link is a re-upload, and the search inside your customer stories hub does a string match against the URL slug instead of the body.

The right home for the working case study is a wiki page. Three reasons:

Searchable by the customer’s problem. A prospect searching “how to migrate a 4,000-page Confluence space” needs to land on the case study that solved that. A PDF won’t index that search; a wiki page will, and pages load in 50–150ms on Raccoon Page, which is the load profile a buyer on a sales call can survive.
Linkable from sales. Sales sends a link, not an attachment. The link is permanent; the page is updated when the customer’s numbers update. Attachments are PDFs of a moment; links are the current truth.
Crossable with the other artifacts. The case study links back to the QBR doc the numbers came from, the team charter the customer wrote with the case study’s framing, and the knowledge-management approach the customer adopted. Three artifacts, one operating loop, one set of cross-links.

The customer-stories index — a single page that lists every case study with the customer fact-row visible — is the actual artifact of your customer marketing programme; the individual docs are the receipts.

You’ll still export PDFs for the email send and the deal-room attachment. That’s fine. The PDF is the screenshot; the wiki page is the document.

Keep it fresh as the customer grows

Every case study decays. The customer’s headcount moves; the pricing model changes; the on-call rotation grows from three engineers to twelve; the “P50 page load: 80ms” number from launch is now “40ms” because the customer’s workload halved or “110ms” because their content grew tenfold. The case study says one thing; the customer’s life says another.

The defence against case-study decay is small habits, not heroic refreshes:

Date every number. “As of May 2026” on the numbers row, and again on each individual datapoint where useful. A number with a date is a number that’s allowed to age; a number without a date is a number that gets quietly contradicted.
Quarterly walkthrough with CS. Once a quarter, the case-study owner and the account’s CSM walk the customer’s page together. Five minutes per case study. Anything significant since the last walk gets a one-line update appended at the bottom and the Numbers row gets an as-of date refresh if a metric has materially shifted.
Archive when the customer’s reality has moved past the story. A customer who’s tripled in size since their case study deserves a second case study, not a forced update of the first. Mark the original “archived — see the 2027 update,” date the link, and ship the new one. Two case studies of the same customer at two scales is better than one case study that’s a year out of date.
Owner per case study has the ping. Same shape as runbooks: named owner, calendar reminder, quarterly cull. Case studies nobody walks are case studies nobody trusts.

The cheapest move on this list is the first one. A case study with dated numbers is a case study that doesn’t need a refresh project; it needs a small edit every other quarter and a fresh walk every fourth. Pick the cheapest discipline that fits the job — same logic, by the way, applies to wikis: our Free tier — three users, one space, a hundred pages, no card — is the right home for the first case study a small team writes; if and when the programme grows beyond a handful of customer pages, the Team tier at $8/user/month is the honest math.

A note on Raccoon Page itself: we’re a wiki, not a CRM. The case-study programme intersects with the CRM (the customer opted in, the AE flagged the deal, the CSM has the renewal date), and the wiki holds the doc. Two systems, one cross-link.

Things people actually ask

What is a case study, in one sentence? A short written story about one specific customer’s situation, the decisions they made, and the measurable outcomes — written in the customer’s voice where useful, attributed and dated, ranging from 800 to 2,000 words, and signed off by the customer before it ships.

What’s the difference between a case study and a customer quote? Scope. A customer quote is one to three sentences of attributed voice; a case study is a 800–2,000-word story with situation, decisions, and numbers. Both come from the same interview; they serve different surfaces. Quotes go on the homepage; case studies go on the customer-stories page and into the deal room.

How long should a B2B case study be? Eight hundred to two thousand words for the body of the case study, plus a short fact-row and a quote panel. Longer than that and you’re writing a white paper; shorter and you’re writing a testimonial. The five-minute read is the right shape for a buyer who’s mid-evaluation.

Who should write the case study? Whichever role on your team owns customer-facing publishing — usually product marketing at companies with one, customer success at companies without. The writer should not be the account executive. The AE produces the opt-in; the writer produces the artifact.

What questions should I ask in the interview? The seven listed above, in order, plus “What would you tell a peer at another company who’s where you were six months ago?” as the closer. Record with consent; transcribe immediately. Schedule a second 30-minute call to verify the draft.

How long does the approval workflow take? Two to four weeks is realistic when the lane is named and the SLAs are explicit. Six months is what happens when the lane is “send it round to people.” The owner re-routes when anyone exceeds their SLA; the named-reviewers rule is what protects against drift.

Should I name the competitor the customer migrated from? Sometimes. The customer’s call to make, not yours. Default: ask, then accept the answer. Public case studies that name a competitor without explicit permission cost more goodwill than they generate.

How often should I refresh a case study? Walk every quarter with CS; refresh the Numbers row when a metric has materially shifted; archive and write a new one when the customer’s reality has moved past the original story. A case study with dated numbers is allowed to age. A case study without dated numbers expires the moment the customer’s reality changes.

Where should the finished case study actually live? In a wiki, as the working source. Exports (PDF, email attachment, deal-room asset) are screenshots of the wiki page, not the home. The link is permanent; the document is current.

If your last case study is currently a Google Doc nobody owns and an email thread with the customer’s legal team that died in March, the upgrade isn’t a new format — it’s a named owner, a seven-section template, and a wiki page the AE can link to instead of attaching. Try the Free tier on the case study you’ve been meaning to write for the customer who keeps asking when their story is going up; even one short, dated, owned case study is more useful than three drafts on a shared drive. If the next prospect can’t find it, write to us; we want to know which folder it lived in.