Case studies: how to show what you do when your work isn't visible

A case study is the strongest proof a sales team can show: a real client, a real problem and what was done to solve it. Putting one together can be very easy or very hard depending on what you sell. I see it every day, because I run sales for two companies in the group I work for, and each one sells something very different.

Why does a case study sell more than a proposal?

When a client hesitates, they almost always ask the same thing: have you done something similar before? A proposal can explain the methodology very well, but that question is better answered by a finished project, with a client who looks like the one in front of you.

Why is it easy at a web agency?

At SSTIL the work is visible. When the web side was still called Minimum, we had an online portfolio with links to the websites we built. Clients would go in, browse a couple of projects and within minutes understand what we could do. Keeping it up was simple, because all you had to do was add the link to each finished website, and it brought in a lot of sales.

Why is it so hard in automation and apps?

At NocodeHackers the work has two sides. In operations we optimize processes, and in applications we build products. Both are hard to show.

A process that works better doesn’t have a URL. The result lives inside the client’s company: an internal tool only their team sees, a flow with fewer steps and fewer emails going back and forth. And clients often prefer not to be named, because what we built touches their day-to-day operations.

An example: we built a system for a pharmaceutical company to manage the creation and certification of its materials. It’s a multi-stage flow, with medical and legal reviews along the way. It works and they use it every day, but it’s hard to explain with a screenshot.

How are we putting it together?

In September we started a project with the NocodeHackers marketing team to organize the case studies into three lines: operations, apps and websites.

Before writing anything, I talked to a colleague at another company in the group who reviews a lot of case studies, to understand what he looks for when he reads one. That conversation produced a three-layer framework every case study has to answer, in this order:

Who the client is and why they matter.
Who was suffering the problem inside the client, and what the business pain was.
What was built, how it was built and what result it had.

With that framework we set up a set of questions in Notion to interview whoever led each project. The marketing team and I split the interviews. The conversation is recorded in Granola and Claude organizes it into a file with the same format for every project, just like I do with sales calls. Those files make up a repository in Notion, and that’s where what we later publish comes from.

What changes depending on the type of project?

In operations, the first two layers matter more. Buyers need to recognize their problem before they understand the solution, so the case study has to say who was suffering it, which metrics were affected and how the project was run, even if that methodology has to be reconstructed afterwards.

In apps you have to earn credibility. Clients want to know whether we’ve built something similar, and for that you have to show what was done and which technical decisions were made. Saying it shipped fast isn’t enough.

In both cases, what convinces people most is the client’s own words. A quote from someone who uses what we built is worth more than any paragraph of ours, and it’s also the hardest thing to get.

And when the client doesn’t want to be named?

That’s the part we’re still working out. What we’re trying is telling the model without the brand.

The first result is this page for record labels, built from an operations project with a record label. It doesn’t name anyone. It describes the problems that keep coming up at labels, how we solved them and how that model ended up being adopted in other markets in the region. A label reading it can recognize its own operation without knowing who the client was.

What I take away

For years I sold with a portfolio that explained itself. Now I sell projects that aren’t visible, and that forced me to get organized about how we tell what we do. We still need more interviews and client quotes, but the system is in place and the next step is filling in the missing files.

If showing what you do is hard at your company too, I’d like to hear how you’re handling it.