Agency Case Studies That Win Work: Structure, Metrics, and What to Leave Out

A case study that describes your process in detail and ends with “the client was satisfied” converts at roughly the same rate as not having a case study at all. The prospect reading it learns that you do the work, which they already assumed. What they need to know is whether you can solve their specific problem.

Most agency case studies fail because they’re written for the agency, not the reader. They document what the agency did. They should document the client’s decision-making context and what changed as a result.

The Structure That Works

Every case study that converts well has the same bones:

The situation. What the client’s business looked like before you started, in terms the client would use to describe their own problem. Not “our client needed a new website.” Something like: “The company was handling 40% of their customer inquiries manually because their CRM couldn’t connect to their booking system. One employee spent six hours a day on data re-entry.”

The constraint. What made this harder than it sounds: budget, timeline, technical debt, stakeholder alignment, a decision that hadn’t been made yet. Constraints make the story real. A project with no obstacles isn’t a case study; it’s an invoice summary.

The approach. What you decided and why, not what you did hour by hour. Clients don’t need to know you held three workshops. They want to know what options you considered and why you made the calls you made. This is where your expertise shows — not in the output, but in the judgment.

The outcome. What actually changed for the client. Measured where possible. Honestly attributed.

The Metrics That Matter

The instinct when writing outcomes is to cite numbers that impress developers: “We reduced API response times from 800ms to 120ms” or “We deployed using CI/CD with 97% test coverage.” Prospects don’t know what to do with those numbers because they have no reference point.

What they understand is the connection to their business: “Checkout page load time dropped from 4.2 seconds to 1.1 seconds, and the client’s conversion rate improved by 18% in the following quarter.”

The technical improvement led to the business improvement. You need both, in that order.

Good outcome metrics, roughly ordered by how convincingly they land with non-technical buyers:

• Revenue or conversion rate changes
• Cost reduction (support tickets handled, manual labor hours recovered, infrastructure spend)
• Time savings (staff hours freed per week, time-to-market improvement)
• Error rates or incident counts before and after
• User satisfaction scores if you measured them

If you don’t have exact numbers, use ranges or honest approximations: “The client recovered approximately 25 staff hours per week based on post-launch tracking.” Vague numbers without framing are worse than no numbers. Approximate numbers with honest caveats are acceptable.

Getting Sign-off from Clients

The main reason agencies don’t have case studies: they never asked, or they asked after the relationship had cooled.

Ask during the project, not after. When you hit a milestone where something went well, send one sentence: “This is shaping up to be a strong portfolio example — would you be open to us writing it up?” Most clients say yes at that point, because you’re still in the relationship and they’re pleased with the work.

What clients typically worry about:

• Competitors seeing specific business metrics (revenue figures, conversion rates)
• The case study implying they had a problem they’re embarrassed about
• Details they consider proprietary or competitively sensitive

Resolve these before writing. Ask directly: “Are there numbers or specifics you’d prefer we not publish?” Then write around those constraints. It’s much easier than revising a finished case study after a client sees something they didn’t expect.

For clients who won’t approve a public case study at all, ask for a private reference: someone a prospect can call. That’s more valuable than a published write-up anyway, because the conversation can address the specific prospect’s concerns in real time.

Format and Length

For website case studies, 400 to 800 words is the right range. Longer and prospects stop reading. Shorter and there’s no story to follow.

Page structure that gets read:

1. One-sentence outcome summary at the top (this is what people skim for)
2. Brief company context — two sentences, enough to be relatable
3. The problem in the client’s terms
4. The key decisions you made and a sentence on why
5. The outcome in detail
6. A client quote if you have one

The quote matters, but not because prospects assume you’ve picked the most flattering one. A specific, concrete quote signals that the relationship was real and that the client was invested enough to articulate what changed. “Before this, we were spending Tuesday afternoons manually reconciling data from three systems” is far more credible than “Working with the team was a great experience.”

Where to Put Case Studies

The least effective placement: a “Case Studies” page buried in the navigation that prospects only visit if they’re already nearly decided.

More effective placements:

• Embedded on service pages, matched to the relevant service (“Here’s what this looked like for a SaaS client with a similar integration challenge”)
• In proposals, where you pick the two or three most relevant to the scope at hand
• In follow-up emails for leads who made contact but haven’t responded
• As individual articles on your blog, which get indexed and found through search

The blog article format works because it can attract organic search traffic from prospects who have the same problem your case study client had. If your write-up covers how you integrated a CRM with a booking system for a healthcare practice, someone searching that specific problem might find it. A prospect who finds you through a problem they recognized is already qualified in a way that most marketing-driven leads aren’t.

What to Leave Out

Your process in detail. Clients don’t buy process; they buy outcomes. Methodology details belong in your proposal, where they’re specific to the scope. In a case study, they’re filler.

Team composition. Unless the team structure was an unusual part of the solution (you embedded a developer on-site for a month, you ran a parallel team for speed), it’s noise.

Tech stack decisions that clients don’t have context for. If the stack choice was a key decision that shaped the outcome, explain why it mattered. If it was just what you used, leave it out.

Anything the client hasn’t verified. Numbers you estimated, outcomes that may have had other causes, improvements that happened three months later with unclear attribution. If you’re not confident in it, caveat it explicitly or cut it. A case study that gets called out for loose attribution does more damage than no case study.

---

The goal of a case study is one sentence: we had a client with exactly this kind of problem, and here’s what happened. Everything else in the write-up is support for that sentence. If a section doesn’t support it, cut the section.