Five mistakes teams make with case studies
The gap between knowing this and actually doing it is where most teams lose ground. These are the ones we run into repeatedly when we audit case studies.
Pages that answer a real question outlive pages written to fill a slot in a sitemap. It is the sort of thing that looks like polish right up until it costs you an enquiry.
Warning signs
- Treating it as a launch task rather than an ongoing one
- Assuming someone else already owns it
- Problem, approach, result, in that order
- Numbers make it credible
- Never checking whether the fix actually worked
Name the client if they will let you. None of that requires a large budget, only a decision and someone to own it. It rarely shows up as a line item, which is exactly why it slips.
What to do next
The short version
Writing for the web is largely an editing job: the first draft is always longer than it needs to be. Three things worth confirming about case studies before you move on:
- Someone can say what the current setup is without going to look
- Numbers make it credible — and you know whether that is true here
- There is a way to tell whether the last change to this helped
Most of the value here comes from doing the first two things, not all of them.