How to write a case study that doesn’t read like a sales sheet

You can spot a bad case study by its opening line. “Company X was struggling with inefficiency and needed a solution.”

Nobody talks like that. No customer, in the history of customers, has ever described their own problem using the word “inefficiency” unprompted.

That sentence is what happens when a case study gets written from a template instead of from an actual conversation.

I’ve written a fair number of these, across manufacturing, IT, and industries that don’t often get treated as interesting on paper.

Here’s the thing I’ve learned doing it.

A case study is a story with a customer in the lead role, not an advert wearing a customer’s name as a disguise.

Get that distinction right and everything else follows.

Start with a real problem, described in the customer’s own words

Bad case studies open with a manufactured problem statement, vague enough to apply to almost anyone.

Good ones open with the specific, slightly messy thing that was actually going wrong.

• Sales sheet version: “The client needed a more efficient way to manage their operations.”
• Real version: “Every Friday, someone on the ops team spent two hours manually cross-checking delivery schedules against a spreadsheet that was out of date by Wednesday.”

The second one is a scene. You can picture it. The first one could describe literally any company that has ever existed, which is exactly the problem.

If your case study’s opening paragraph would work for a different client with the name swapped out, it’s not doing its job yet.

How to get there: Ask the customer what the old process looked like, day to day, before you ask them what the new one looks like.

Most interviewers skip straight to the win. The mundane detail before the fix is where the credibility lives.

Let the customer sound like a person

There’s a particular flatness to quotes like “the team was fantastic and the results speak for themselves.”

It’s not that the sentiment is false. It’s that it’s been smoothed until there’s nothing left to believe.

• Flat quote: “The platform has really streamlined our workflow and improved our results.”
• Quote with a pulse: “I used to dread Monday mornings because I knew I’d spend the first hour just figuring out what had gone wrong over the weekend. Now I genuinely don’t think about it, which sounds small, but it’s really not.”

How to get there: Ask follow-up questions in the interview instead of accepting the first polished answer.

“What did that actually feel like at the time” gets you further than “how would you rate the experience.”

People remember feelings and specific mornings, not KPIs, at least not in the way they talk about them out loud.

Show the work, not just the outcome

A lot of case studies skip straight from problem to result, as if the solution appeared fully formed.

That’s the least trustworthy part of most case studies, because readers know that’s not how projects actually go.

Nothing goes that smoothly and everyone knows it.

• Skip-the-middle version: “We implemented the solution and the client saw a 40% improvement.”
• Show-the-work version: “The first version didn’t account for how the team actually used the tool on the shop floor, so we adjusted the rollout after week two. By month three, that adjustment had brought reporting time down from three hours a week to under thirty minutes.”

How to get there: Ask what almost went wrong, or what had to change partway through.

Readers doing due diligence on a purchase decision are more reassured by a bump in the road that got handled than by a story with no bumps at all, because the second one doesn’t match their own experience of how projects work.

Use numbers, but only ones you can defend

Numbers matter in a case study and skipping them entirely leaves it feeling soft.

But a number with no context is just decoration.

• Decoration: “Increased efficiency by 60%.”
• Defensible: “Cut the weekly reporting process from three hours to just over one, freeing up roughly two working days a month across the team.”

How to get there: Ask what the number replaced. A percentage on its own is a marketing claim.

A percentage attached to a real before-and-after is evidence and evidence is what a case study is supposed to be providing in the first place.

End on what changed, not on a slogan

The instinct at the end of a case study is to zoom out and get grand: “a true partnership for the future” or some variation on it.

It’s the moment where a genuinely good case study is most likely to lose its nerve and revert to sales language right at the finish line.

• Slogan close: “This partnership exemplifies our commitment to delivering excellence.”
• Real close: “Eighteen months on, the ops team has stopped dreading Fridays, and that two-hour manual check hasn’t returned.”

How to get there: End on the same specific, human detail you opened with. If you started with the Friday spreadsheet problem, close by telling the reader what happens on Fridays now.

It ties the story together and it’s a far better proof point than a line about excellence that could be lifted straight out of any other company’s case study.

The short version

A case study reads like a sales sheet when it’s written to describe an outcome.

It reads like a story worth trusting when it’s written to describe a specific problem, a specific person’s experience of it and a specific change that followed.

That takes a better interview, not better copywriting and it’s usually the interview most businesses rush.

If you’ve got a good customer result sitting untold because nobody’s got round to writing it up properly, get in touch and we’ll turn it into something worth reading.