The standard B2B SaaS case study format hasn’t materially changed in fifteen years. Customer logo at the top. Three-line intro. “The Challenge.” “The Solution.” “The Results.” A pull quote. A metric or three. Done.
I’ve produced something like 30 case studies across our client portfolio in the past year, and I will tell you with confidence: this format is mostly useless. Sales teams don’t use them because prospects don’t trust them. Prospects don’t trust them because they read like sanitized PR. AI engines don’t cite them because the structured-fact density is too low. They exist mostly as wall ornaments and procurement-process checkboxes.
Why the standard format fails
- No failure data. Every case study has the same arc: customer had problem, customer adopted product, customer’s life improved. Real adoption stories include false starts, partial failures, scope changes, surprises. Removing those makes the narrative implausible to anyone who’s actually run a software adoption.
- Vague metrics. “Saved 40% of time” is meaningless without baseline and counterfactual. Saved 40% of what time? Vs. doing nothing? Vs. doing the old way? Over what period?
- Missing context. What size was the team? What was the prior tool? Why this product over the obvious alternatives? Most studies omit this to avoid endorsing competitors, but the omission is what makes the case feel like marketing.
- Customer voice ghostwritten away. Most case study pull quotes are written by the vendor and approved by the customer. Readers can feel this. They sound like a customer-shaped vendor saying vendor-shaped things.
What I do instead
The frame I use now is operator-to-operator notes, not vendor-to-prospect marketing. The implied reader is someone considering the same project and looking for an honest account of what it actually took. The format I aim for:
- The actual situation. Two-paragraph setup. Stage, ARR range, team composition, prior tooling, what was forcing the change. Specific.
- The decision criteria. What other tools were evaluated. Why this one. What was given up by choosing it. This last part is where most case studies refuse to go, and it’s exactly where prospects are most desperate for honest input.
- What went well in the first 90 days. Specific outcomes with baselines.
- What didn’t go well. Yes, include this. Friction in rollout, features that took longer to land than expected, integrations that broke, team members who pushed back. Customers respect vendors who can write this honestly, and prospects find it much more credible than the everything-was-perfect version.
- The 12-month outcome. The metric that matters, baseline included, methodology disclosed.
- What I’d tell a peer considering this. Direct first-person advice to a reader in the same situation. This is where the case becomes useful as a sales tool and as a citable source for AI engines.
Getting customers to talk this honestly
The friction isn’t the customer — it’s usually the customer’s marketing team. The actual operator is often happy to be honest; the operator’s CMO wants the polished version. Two tactics that work:
- Conduct the interview in operator-to-operator framing. Tell the interviewee you’re writing this for peers, not for marketing. Specifically: “I want the version you’d tell someone over coffee, not the version you’d put on your company’s blog.” The shift in answer quality is dramatic.
- Get customer marketing review last, not first. Draft from the interview transcript. Show the customer the draft. Get their personal sign-off. Then route through their marketing team for approval. By the time it reaches CMO review, the operator is already on record approving the honesty.
The composite case study problem
One last thing. We publish anonymized composite case studies for confidentiality reasons. Many vendors do the same, and most of them aren’t transparent about it. Always disclose when a case study is composite or anonymized. Hiding the composite nature is the kind of credibility hit you don’t recover from when discovered.
— Isabela
