How To Write A Case Study

A case study's job is to make a result believable by showing the specific, verifiable path that produced it. The format fails when it turns into a company achievement announcement with a customer's name attached — it works when a reader who has never talked to you can follow exactly what the problem was, what was actually done about it, and how the outcome was measured.

Pick a project that can carry the weight

Not every successful project makes a good case study. Look for one where you have three things at once: a customer willing to go on record, results you can actually point to (even directionally, not just "it went well"), and a problem specific enough that the reader can picture their own version of it. A case study built around a vague win ("we helped them grow") reads as filler no matter how well it's written; one built around a narrow, concrete problem ("their onboarding emails had a 4% open rate and support was fielding the same three questions daily") gives you something to actually resolve on the page.

Get the material before you start writing

Most weak case studies aren't badly written — they're written without enough raw material. Before drafting, get:

• A real interview with the customer, not just an email exchange. Ask what the situation was before, what almost stopped them from working with you, and what changed afterward — in their own words. Direct quotes are what separate a case study from marketing copy.
• Whatever data actually exists. Not every result is a clean percentage. If the honest answer is "support tickets dropped noticeably but we don't have an exact baseline," say that rather than inventing a number that sounds more precise than what you actually measured.
• Written permission to use the customer's name, quotes, logo, and any figures you plan to publish, ideally set out plainly in an email or a short release rather than assumed from a verbal okay.
• The internal side of the story — what your team actually did, in what order, and why, from whoever ran the project.

Structure it around the problem, not the product

A case study that opens with your product's feature list has already lost the reader. Open with the customer's situation instead:

1. Context — who the customer is and what mattered about their situation before anything changed. One or two sentences of company background is usually enough; the reader doesn't need a full profile.
2. The problem — specific and concrete. What was actually failing, costing money, or blocking the team, and what had they already tried?
3. The approach — what was actually done, including any decisions or trade-offs made along the way. This is the part that gets skipped most often, and it's often the most useful part for a prospective customer trying to judge whether the same approach would work for them.
4. The outcome — what changed, over what time frame, measured how. If you have a real number, use it and say how it was measured. If you only have a qualitative account, say so rather than dressing it up as something more precise.
5. A direct quote from the customer, ideally more than one, placed where it reinforces a specific claim rather than as a generic closing testimonial.

Be precise about numbers — including their limits

Specificity is what makes a claim believable, but specificity only helps if it's accurate. "Response time improved" is weak. A concrete, sourced figure — "average first-response time dropped from roughly six hours to under one" — is strong, but only if that's genuinely what was measured and over what period. Don't manufacture false precision: if the customer told you results "roughly doubled" rather than giving you an exact figure, write it that way. A reader who later finds out a specific-sounding number was invented will discount every other claim in the piece, and possibly everything else you publish.

Common ways case studies undercut themselves

• No real problem statement. If the reader can't tell what was broken beforehand, the resolution doesn't mean anything.
• All company, no customer. A case study that spends most of its space describing your product's capabilities rather than the customer's experience reads as an ad wearing a customer's name.
• Testimonial without substance. "They were great to work with!" doesn't tell a prospective customer anything actionable. A quote that describes a specific moment or specific outcome does.
• Invented or rounded-up numbers. If you're not confident in a figure, hedge it honestly rather than stating it as fact.
• No visible sign-off trail. If you can't produce the customer's approval for what's published, you're one complaint away from having to take the piece down.

Interview the customer like a reporter, not a fan

The interview is where most of the case study's real material comes from, and it's worth treating it as a genuine information-gathering conversation rather than a chance to collect praise. A few questions tend to produce the most usable material:

• "What were you doing before, and what wasn't working about it?" — this gets you the problem statement in the customer's own words, which is almost always more specific and more credible than anything you'd write on their behalf.
• "What almost stopped you from moving forward?" — hesitations and objections, once resolved, make a case study more persuasive to a skeptical reader than a frictionless success story would.
• "What changed, specifically, and how did you notice it?" — pushing past "it's been great" to a concrete before-and-after detail is usually where the best quote in the piece comes from.
• "Is there anything you'd want a similar company to know before they start?" — this often produces the closing quote, and sometimes surfaces a nuance (a slower ramp-up period, a specific prerequisite) that makes the whole piece more trustworthy for being included rather than glossed over.

Record the conversation if the customer is comfortable with it, and quote them precisely rather than smoothing their words into more polished marketing language — a slightly rough, specific quote reads as more authentic than a suspiciously perfect one.

Where a case study actually gets used

Where the piece will live affects how you should write it. A case study meant to close deals in a sales process often needs a short, skimmable version a prospect can read in two minutes, sometimes as a PDF a sales rep sends directly. A case study meant to attract organic search traffic needs to actually answer the questions a searcher researching the same problem would have, which usually means more explanatory detail about the approach, not just the outcome. Writing one version and trying to force it to serve every channel usually means it serves none of them particularly well — it's worth deciding the primary use case before you start structuring the piece.

Length and format

There's no fixed rule for how long a case study should run — a short, focused version (a few hundred words) can work well as a landing-page element, while a fuller narrative version with more of the interview woven in might run to 1,000–1,500 words as a standalone page or PDF. Match the length to where it will actually be read rather than padding it to hit a target word count.

The most useful habit, more than any structural template, is treating the case study as an honest account you could defend line by line if the customer read it back — because eventually, they will.

FAQ

Does a case study need a named customer, or can it stay anonymous? Named and quoted is far more persuasive, but an anonymized version ("a mid-sized logistics company") with real specifics and a real, attributable quote from "their operations lead" can still work when a customer is willing to share the story but not their name — it's a reasonable compromise, not a first choice.

Who should actually write it — the customer's words, or yours? Both: the structure, framing, and connective narrative are yours, but the most persuasive specific claims and the testimonial language should be the customer's actual words from the interview, not language you've written and asked them to approve.

What if the results genuinely weren't dramatic? Write it honestly rather than inflating it. A modest, credible result described precisely is more useful to a skeptical reader than a dramatic-sounding claim they don't believe — and it protects your credibility for the next case study, where the result might be stronger.