Case study copy: problem, fix, change. In that order.

A case study should be written in three parts, in this order: the problem the client had, the fix you shipped, and the change it produced. Problem, fix, change. Anything that does not fit one of those three buckets is padding, and padding is the reason most case studies read like brochures.

I have written and edited a lot of these. The ones that convert new clients follow the same shape. They open with a real problem a reader recognizes as their own. They explain what was done in plain terms. Then they show what changed, with numbers where numbers exist. This post walks through each part, why the order matters, and where people go wrong.

Why does the order matter so much?

The order matters because a reader has to feel the problem before they care about the fix. If you lead with the fix — or worse, with how great your firm is — the reader has nothing to attach it to. They skim. They leave.

Think about how a prospect reads a case study. They are not reading to admire you. They are reading to answer one question: "Is my situation like this one?" That question lives in the problem section. If your first paragraph is about your process, your awards, or your years in business, you have answered a question nobody asked.

Problem first pulls the reader in. Fix second earns their trust. Change last gives them the proof they need to pick up the phone. Reverse any two of those and the story falls apart. A change with no problem is a brag. A fix with no problem is a manual. The order is not a style choice. It is how belief gets built.

This is the same logic behind good positioning. You start with the client's world, not yours. If that idea is new to you, we covered it in positioning, not branding — the case study is just positioning told as a story about one person.

What goes in the problem section?

The problem section describes the client's situation before you arrived, in their words, with enough detail that a stranger with the same problem sees themselves. It is the most important part and the part most people rush.

Write the problem as the client would describe it at the start. Not the diagnosis you reached later. The symptom they felt. A San Diego dental practice does not walk in saying "my local pack ranking is weak." They say "the phone stopped ringing and I do not know why." Use that. The symptom is what a new reader recognizes.

Name the stakes. What was the problem costing them. Empty chairs. A calendar with gaps. Two hires they could not justify. Money makes the problem concrete. "They wanted more visibility" is vague and forgettable. "They were spending $6,000 a month on ads and could not tell which calls came from where" is a problem a reader feels in their chest.

Keep it specific and short. Three or four sentences is often enough. You are not writing a case history. You are setting up the fix. The test for this section: could a competing business owner read it and think "that is exactly my situation"? If yes, you have done the job. If they think "that is a nice generic intro," start over.

A common mistake is hedging the problem to protect the client's ego. Do not. A problem that sounds mild produces a fix that sounds unnecessary. The client agreed to be in the case study. Let the problem be real.

How do you write the fix without it sounding like a brochure?

Write the fix as a sequence of decisions and actions, in plain language, tied back to the problem you just named. The brochure version lists services. The good version explains what you did and why it followed from the problem.

Here is the difference. Brochure: "We provided a full technical audit, on-page optimization, and content strategy." That is a menu. It tells the reader nothing about their situation. Good version: "The site had four pages competing for the same search. We merged them into one, rewrote it around the question people actually type, and fixed the load time that was pushing the page down." Same work. But now the reader understands the reasoning.

Tie every action to the problem. If the problem was "the phone stopped ringing," the fix section should explain what was stopping the calls and what you changed. Do not introduce work that does not connect to the stated problem. If you did other work, it belongs in a different case study or not at all. One problem, one fix, one change. Discipline in scope makes the story land.

Avoid jargon a client would not use. "We improved crawlability" means nothing to a plumber. "We fixed the reason Google could not read half the pages" means something. Write for the prospect, not for other marketers.

Name the tradeoffs where they existed. "We recommended dropping two service pages that ranked for nothing" is more believable than a fix where every decision was easy. Real work has tradeoffs. Showing one or two makes the whole story credible. This honesty is part of how we describe our own work in brand building and startup roadmaps — the plan is only useful if the reasoning is visible.

What makes the change section believable?

The change section is believable when it uses specific numbers, names a time frame, and ties the result back to the original problem. Vague outcomes kill credibility faster than no outcomes at all.

"Traffic increased significantly" is worthless. Significant to whom. Over what period. From what baseline. Compare that to: "Calls from search went from 11 a month to 34 a month over five months." The second sentence is checkable. It sounds like it happened because it did.

Use the metric that matches the problem. If the problem was empty chairs, the change is booked appointments, not impressions. If the problem was wasted ad spend, the change is cost per booked client. A reader who felt the problem in the first section wants to see it resolved in the last section. Same unit of measurement, start to finish. That symmetry is what makes the story feel whole.

Give a time frame. Results without a clock are suspicious. "Over six months" or "within the first quarter" tells the reader this took real time, which is honest, and it sets their own expectations. A change that appears to happen instantly reads as fiction.

When you can, add a line in the client's voice. Not a scripted testimonial. A real sentence. "I stopped checking whether the ads were working because the calendar filled up." That kind of line does more than a chart. Our write-up on Dr. Julia Souvorova follows this shape — a clear problem, the specific work, and a change stated in numbers a reader can hold onto.

Where numbers do not exist yet, say so. "The site launched in March and early call volume is up" is honest and still useful. Do not invent precision you do not have. A prospect can smell a rounded-up number.

A short checklist before you publish

Run every case study through this before it goes live. It catches the most common failures.

1. Does the first paragraph describe a problem a reader would recognize as their own. If it describes you, rewrite it.
2. Is the problem specific enough that a stranger sees themselves in it. Vague problem, weak case study.
3. Does every action in the fix connect to the stated problem. Cut anything that does not.
4. Is the fix in plain language a client would use. No jargon the reader would have to look up.
5. Does the change use the same unit as the problem. Empty chairs to booked chairs. Wasted spend to lower cost per client.
6. Are there real numbers and a time frame. No numbers, name the honest limit instead.
7. Could the client read this and say "yes, that is what happened." If not, you have written fiction.

Most case studies fail on the first and third points. They open with the firm instead of the client, and they list services instead of connecting work to the problem. Fix those two and you are ahead of nearly everyone in your market.

One more thing on sameness. If your case studies could have the client's name swapped out and still read fine, they are too generic to help. The details are the proof. We wrote about this pattern in why most small business positioning statements sound identical — the same trap catches case study copy. Specifics are the only defense.

What this format does not fix

This structure will not save a case study built on a client who barely changed. If the work did not move anything, no writing framework will hide that. Pick clients with real before-and-after gaps to write about.

It also will not replace permission and honesty. Get the client's sign-off on the numbers and the story. And if a result was partly luck or timing, say so. A case study that admits one thing went the client's way is more believable than one where you take credit for everything. Problem, fix, change — told straight, with the parts in order, is enough.