Case studies that close deals

Pull up ten case studies from ten different B2B vendors and read only the openings. Eight will start the same way: a one-sentence description of the client's industry, followed by a sentence that begins "They were facing challenges with..." Close your eyes and you cannot tell one company from another. That is not a coincidence of bad writing. It is what happens when a case study is written to make the client comfortable and the vendor look good, in that order, with the reader's actual question addressed nowhere.

The reader's actual question, when they are far enough into a live evaluation to be reading your case studies at all, is narrow and specific: has this company handled a situation shaped like mine. Not "are they good at this in general" — they have already half-decided that from the demo. What they are checking, page by page, is whether the vendor has scar tissue from something that resembles their own budget, their own legacy system, their own internal approval chain. A case study that cannot answer that question is not read closely. It is skimmed for the logo and the number, and then closed.

Lead with the situation, because that is the only part a reader can match against their own

The standard case study structure buries the situation in a paragraph and gives the result three paragraphs and a stat block. That ordering optimises for the wrong reader. It is written for someone deciding whether the vendor is impressive in the abstract, and it serves almost nobody, because the person reading it during an evaluation is not asking whether you are impressive. They are asking whether you would have understood their specific mess.

Reverse the emphasis and the case study becomes something closer to a diagnostic tool for the reader. Open with who the client was and what shape their problem took, in the amount of detail an operator would recognise as real: not "a mid-sized logistics company" but "a logistics company running dispatch on a system installed in 2011, with three regional offices that had each customised it differently, and no single person who understood all three customisations." That sentence does work a generic one cannot. A reader running a comparable system reads it and thinks, correctly, that this vendor has been inside a mess like theirs before. A reader who is not in that situation skims past it in five seconds, which is fine — they were never going to be persuaded by this particular story anyway, and a case study does not need to persuade everyone. It needs to be unmistakable to the one reader it is for.

This is also the argument for several case studies rather than one polished flagship. Different readers arrive with different shapes of problem, and a single glossy story only matches one of them — which is also why the services page and the case studies archive should be built to the same logic: specificity over polish.

Name the constraint, or the reader assumes there wasn't one

Every real project has a constraint that made it hard, and almost every published case study edits that constraint out. The budget was smaller than the scope wanted. The timeline was set by a board meeting, not by the work. The client's legacy system could not be touched, so the new thing had to work around it rather than replace it. Someone internally did not want this project to happen and had to be brought along or worked around. These are the details that get cut in the review pass, usually at the client's request, sometimes because the vendor decided unprompted that admitting friction makes them look worse.

It does the opposite. A case study with no named constraint reads as a project that had no resistance, and every reader who has run a real project knows that no project has no resistance. The absence does not read as "this one went smoothly." It reads as "this account of it has been edited," and an edited account is worth exactly as much as the reader's trust in the editor, which by this point in the sales process is not much.

Naming the constraint does something else too: it is the fastest way to make the case study relevant to a specific reader, because constraints are what actually vary between projects. Two companies solving the same problem where one had six months and a blank slate and the other had six weeks and a system nobody was allowed to touch are different projects that happen to share an outcome. Report only the outcome and you have thrown away the one piece of information that would let a reader tell whether their situation matches.

An unqualified percentage reads as invented, because it usually is one

"Reduced processing time by 40%." Read on its own, that number does no work. Forty percent of what? Forty minutes down to twenty-four is a real, checkable claim. Forty percent off a number nobody states could be four minutes to two-point-four, a change nobody would notice, dressed in the same confident percentage as a genuinely large result. A reader who has seen a hundred marketing pages knows this trick, and the effect of using it is not that they believe the 40% — it is that they discount every number in the case study by some private factor, including the ones that were true and specific.

The fix costs nothing and is rarely taken: state the baseline. "Processing time dropped from 40 minutes to 24" is not a more impressive number than "reduced by 40%" — it is the same number, made checkable. A reader can do the arithmetic themselves, which is precisely why it reads as honest. The percentage-only version asks the reader to trust your math. The baseline version lets them verify it, and verified numbers are the only numbers that move a decision made by a skeptical adult evaluating several vendors at once.

The same logic applies to timeframes and sample sizes that case studies routinely omit. "Increased conversion" over what period, based on how much traffic. None of this needs a research department to produce, only the discipline of writing down what you actually know instead of the summary version that sounds better and says less.

Getting the client to approve the honest version

The reason so many case studies are hollow is not usually the vendor's writing. It is the approval process. A client's legal or marketing team reviews the draft, and their job in that review is risk reduction, not persuasiveness. Anything specific enough to be useful is also specific enough to be a liability from their seat — a named budget figure, an admitted internal disagreement, a timeline that makes a stakeholder look like they dragged their feet. The safest move for that reviewer is to cut it, and a case study edited by someone optimising for zero risk converges, project after project, on the same content-free shape.

The way past this is not to ask for approval on the whole document at once. Send a draft that still has the difficulty in it, and ask specifically what they would change and why, rather than a blanket "does this work for you." Most reviewers, faced with a specific question about a specific sentence, will negotiate that sentence rather than demand the whole piece be softened — and a negotiated, slightly hedged version of a true detail is still worth more than its absence. "Budget constraints meant the first phase covered only the two highest-volume regions" survives most reviews. "The project was completed in phases" survives every review and tells the reader nothing.

It also helps to ask the client, directly, what they got out of working with you that they would tell a peer in a similar spot. That answer is usually more specific and more usable than anything a marketing team would draft on their behalf, because it comes from the person who made the decision to hire you.

The anonymised case study, and when it earns its place

Sometimes a client will not go on the record at all, and the honest choice is between an anonymised version and no case study. Anonymising removes exactly the two things that make a case study work — a name a reader can verify against LinkedIn or a company website, and enough specific detail that the situation reads as real rather than composited. "A mid-market SaaS company" carries none of the weight that a named company with a named executive carries, because a reader has no way to check it and every reason to assume the convenient parts were adjusted.

That does not mean anonymised case studies are worthless, only that they are worth less, and should be used sparingly rather than as a default when a client says no. They earn their place when the situation itself is unusually instructive — a failure mode other buyers will recognise — and no named client is available to illustrate it. In that case, keep every specific detail you are allowed to keep rather than smoothing the whole thing into the generic register anonymisation tends to invite. A detailed anonymised story beats a vague named one; it rarely beats a detailed named one.

The more common mistake is reaching for anonymisation as the easy path when a named client was actually available and simply never asked properly. Most clients who are happy with the outcome will agree to be named if the request is specific — this quote, this number, this project — rather than an open-ended ask for "a case study," which sounds like more exposure than it is.

None of this changes what a company website is actually for. A case study sits next to the about page and the services list, and it only earns its space if it does something those pages cannot: prove, with a checkable detail, that the situation the reader is standing in has been handled before. That single test — would this survive being read by someone who was actually there — is worth applying to every case study on the site before the next one gets written, because it is the only test a skeptical buyer is actually running.