How do I write a case study for my SaaS?

What a case study has to do that a testimonial cannot

A testimonial is a person vouching for you. A case study is an argument: that something changed, that your product is why it changed, and that the same change is available to the reader. That is a much higher bar, and it explains why a page full of warm quotes can sit next to a flat signup rate. Quotes establish that you are real and pleasant to work with, and a stranger far enough along to be reading case studies has usually moved past both questions. If proof of existence is what you actually need, collect testimonials instead and spend the saved week elsewhere.

1. A customer the reader recognises. Company size, stage, sector, and the job they were trying to do. Someone scanning your case-study page is looking for themselves, not for your most impressive logo. Two studies of businesses that look like your buyer will out-convert one study of a household name they will never be.
2. The situation before, in their words. What they did instead, what it cost them, and what finally made it urgent. This is the section founders cut for length, and it is the section that does the persuading — it is where a reader decides the story is about their problem rather than your product.
3. What specifically changed. Not a feature list. The one or two things they now do differently, described concretely enough that a reader can picture their own week changing the same way. If the change cannot be stated without naming three features, it is probably not the change.
4. A result with its baseline and its window. A number, what it is measured against, and over how long. A number without those last two is decoration, and an experienced buyer reads it as decoration.

The number is the hard part, not the writing

Most weak case studies are not badly written. They rest on a figure that cannot survive one question from a sceptical reader: compared to what? A claim such as cut onboarding time by 40% is unanswerable unless you also say what onboarding took before, how it was measured, and over what period. Founders skip this because the customer rarely volunteers it and because asking feels like doubting a compliment — but the reader you are trying to convince is exactly the one who will ask.

It is easy to underestimate how quietly a number goes wrong. Our own dashboard at AgentCeres — the AI Growth Officer, agentceres.com — used to compare the last seven days of website sessions against the seven before, anchored on the most recent day of data available. Google Analytics serves a partial row for the day still in progress, so the comparison was really six complete days plus a few hours against seven complete days. In early August 2026 the cards reported a fall of about 20% where the real change was nearer 10%, and that skewed figure was being written into the history our anomaly alerts read. No data was missing and nothing threw an error; the arithmetic was correct on the wrong window. We now drop the day in progress before comparing. A case study built on a number like that is wrong in a way neither the writer nor the reader can detect, which is the practical argument for printing the window next to the result and letting people check it.

What to publish when you have no result yet

The honest position most founders are in is that the customer is happy, the outcome is not measurable yet, and a case study is wanted for a launch next week. Inventing a plausible percentage is the one move that can cost you the deal it was meant to win: a buyer who checks and finds the figure unsupportable stops believing the rest of the page, including the parts that were true. Three alternatives are publishable today, and each is stronger than a fabricated lift.

• Publish the workflow change instead. What the customer stopped doing, what they now do, and who does it. It is verifiable, it is specific, and for most business buyers it is the part they were trying to picture anyway.
• Publish a pilot with a stated review date. Say what you are measuring, and commit in public to reporting it on a date. That is unusual enough to read as confidence rather than hedging, and it gives you a reason to go back to the customer with a real question.
• Use the customer's number, not yours. A figure from their billing system or their analytics, quoted as theirs and dated, carries more weight than the same figure from your product dashboard — because your dashboard is an instrument you built and they did not.
• Say what did not change. A study that names something the product did not fix is markedly more believable than one where every metric improved, and it answers the objection your reader was already forming.

Getting it approved without losing the story

Approval is where most case studies die, usually because the first thing the customer sees is a finished page with their logo on it. A cold draft sent to a marketing or legal contact invites a rewrite that removes every specific and leaves you with a page that says a valued partner improved efficiency. Ask the person you actually worked with first, in plain terms: are they happy to be named, can the number be published, and who else has to see it. Then send the quote on its own rather than the whole page. Quote approval is a small favour; page approval is a project.

If the answer comes back as no name and no numbers, that is still a usable page. An anonymised study — a fifteen-person logistics company in the Netherlands — keeps the recognition that does the work and loses only the logo. What it cannot survive is being anonymous and vague at the same time, so trade the name for more detail elsewhere, never less.

One decision is worth making before you publish: whether you are claiming the result was caused by your product, or that it happened alongside it. That distinction is incrementality, and it is the question a good buyer asks silently while reading. Most case studies are honest associations dressed as causes, and the fix is a sentence rather than a study. If you are not yet sure the underlying change is real, settle the measurement question before you write the story around it.