top of page

How to Write a Case Study that Sings like a Canary on Steroids

Updated: Nov 22, 2022

And adds value to your client.


A company invests in good content to directly or indirectly achieve 1 goal: promote itself. Sometimes it's more blatant when they invest in sales campaigns, social ads, and collaborations that widen their reach to new audiences but then there are also other, more subtle ways.


For the record, let’s not confuse “subtle” with “let’s avoid phrases like Industry leaders with a track record of amazing results” or such indirect tactics of flattery.


It’s just like when during an interview you’re asked to share the best 3 things about yourself. It’s one thing to jump right into “I’m super smart, hard-working, and a team-player”, and another to say:


“I thrive in dynamic environments where multitasking, adapting quickly to new situations, and learning things as we go, are necessary. I'm also a firm believer in teamwork, working together towards the great goal, and helping each other along the way, rather than working on my own objectives."

See what I mean?

I'm talking about informative content that shows a company's expertise in a field and how they achieve results for their clients without sounding sales-y.


The key in case studies is not to focus solely on making your client shine but explain in simple words how the “after” is better than the “before” and what are the benefits for a potential client, in a way that other companies can potentially empathise with. This triggers the curiosity to learn more about the solution and how it can actually help.


What to have in mind when writing an effective case study

The general structure of a case study is:

  • Context about the client

  • The Problem - hat triggered the desire for a change?

  • The Solution - together with information about the implementation

  • Results - initial results

  • Next steps

  • A Brief description of the company selling the service or product

First thing’s first: draw a blank page and create these sections.


Then, start setting up calls with all the parts that were involved!


The first order on the agenda is gathering all the information for each of the sections, directly from the source. Even for the final part where you client is being presented. Sure, you can get details from their corporate website but that’s way too polished and edited.


Speak to the team that implemented the solution or those that managed it, and get insider information about not just the “company of 500 employees with offices in 5 countries…”. That’s important too but it doesn’t add that much value here. You need information like:


“the fact that our first clients were able to implement quickly our solution and saw results during the first few weeks, is what put us on the map and allowed us to grow exponentially over the past years into a company of over 500 people spread around 5 countries.”

Make sure you speak with your client’s team (for the solution, implementation, and company insights sections) and their client’s team (for their context, the problem they needed fixing, why they chose your client, and the next steps).

Record the interviews and then work on transcripts, they’re full of golden nuggets. Plus, more often than not, things can get quite technical and you need to make sure you understood everything right.


Edit the transcripts and start adding some of this content in the draft document, directly in the sections you’ve previously created.

Some tips per section:

  1. The context of the client - include what they do, the history and then dive into their pain points before the implementation, what triggered them to want to make a change, and what they were looking for in a partner for this project.

  2. The problem - describe what they results were and why they weren’t happy, which teams were affected and why, and focus specifically on how was it stopping their growth. This is where others might think “hmm that’s happening to me too…”.

  3. The solution - start off by explaining why they chose your client and not a competitor. What made their solution or product the better match, what did your client promise them, and what technical specifications interested them. Then move onto the technical side: how did the implementation go, how long did it last, what did the team looked like, how did they work, and so on.

  4. The results - be concise, and add as many numbers as you can possibly can. If statistics aren't available, think "are the employees saving time and energy in their day-to-day due to the solution?" (quotes would be great), or "is the morale of the team better?". Talk about any intangible, positive outcomes.

  5. Next steps - this section should be dedicated to what’s the next step in the collaboration: did you client implement a solution and handed it over, or are they offering consulting services and support? What’s the next upgrade? What technologies aren’t yet used but might be integrated in the future?

These make the difference between good copywriting and someone that just gathers information and writes a report.

I can’t stress enough how important research is: from the tone of voice of both your client and the final client, to understanding perfectly what both companies do and what they’re after (the profile of their final client), seeing similar materials they’ve published so you get a sense of what’s expected, and so on. It might seem obvious but research is vital in these cases.


Consider all this and you should end up with the “tell me I’m amazing without saying I’m amazing” you're after.

Diplomacy and the right balance between elevating the 2 companies is very important.

It’s gets easier and more interesting with practice because you constantly learn and also, each client is its own universe so you're never bored.


I like writing case studies because they’re always a challenge on many levels: how do I know what information to ask for, how to I turn highly-technical texts into digestible materials, how do I find the right balance between speaking highly of both companies but shed light on my client, and most importantly, how do I turn a document seemingly not for everybody into something that someone will want to read even if they’re not in the market for the solution this company is offering?


It’s good, interesting work and you come out smarter. And if you word hard at finding the right words for describing something very technical, you get the satisfaction of making something rigid, sing like a canary on steroids.

But that’s just me… thinking out loud.

bottom of page