By Mehdi HassanA case study is the strongest proof a B2B site can publish, and the one most often wasted. Many read like press releases: the customer's name, a list of deliverables, and a vague line about a 'great partnership'. This template structures a case study page around one outcome a buyer cares about. It's the structure we use for our own project pages, and it sits within our broader guide to social proof on landing pages.
How should a B2B case study page be structured?
A B2B case study page should follow the buyer's questions in order: what happened, who was it for, what was wrong, why did they choose you, what did you do, what changed, and what should I do next. Lead with the outcome so a skimmer gets the point in five seconds, then give the detail a serious evaluator needs.
Section | Question it answers | Length |
|---|---|---|
1. Outcome headline | What happened? | One line |
2. Summary box | Is this worth reading? | Four short fields |
3. The customer | Are they like us? | Two to three sentences |
4. The problem | Do they have our problem? | One short section |
5. Why they chose you | What were the alternatives? | One short section |
6. What was done | How does it work in practice? | The longest section |
7. The results | Did it really work? | Numbers plus context |
8. Quote and next step | What would they say? What do I do now? | One quote and one CTA |
What goes in the case study headline and summary box?
The case study headline should state the outcome in plain words, and the summary box should give the whole story in four fields. Together they let a reader who never scrolls still walk away with the proof. Many buyers, and the AI engines that summarize pages, will only use this top section.
- Headline: the result, with a number if you have one, and the customer's type. For example: 'How a fintech team cut onboarding from three calls to one'.
- Customer: name, industry, size and stage, plus a logo.
- Challenge: one sentence on the problem in the customer's terms.
- Solution: one sentence on what you did, without jargon.
- Result: the headline outcome and up to two supporting results.
How do you write the problem and decision sections?
Write the problem section in the customer's words, describing what was happening and what it cost them, so a prospect with the same problem recognizes themselves. Then write the decision section honestly: what alternatives the customer considered, including doing nothing, and why they chose you.
These two sections do the persuasion that the results can't. A buyer who sees their own situation described accurately trusts everything that follows. The decision section handles objections indirectly. If the customer worried about switching costs and chose you anyway, say so, and say what reassured them. The raw material comes from an interview, using the questions in our guide to getting testimonials that sell. The customer's own language often becomes useful copy elsewhere, which is why it belongs in your messaging framework too.
How much detail should the solution section include?
The solution section should include enough detail that a buyer understands how the result happened, and could explain it to a colleague, but not so much that it becomes a project log. Focus on the three or four decisions that mattered, why they were made, and what was delivered.
Start with the approach
One paragraph on how you tackled it, such as 'we started with the words before any design'.
Name the key decisions
Three or four choices that shaped the outcome, each with the reason behind it.
Show the work
Screenshots, before-and-after comparisons or short clips. Visual proof is harder to doubt.
Be honest about trade-offs
What you deliberately didn't do, or what was hard. It makes the story believable.
Close with what was delivered
A short list: pages, assets, integrations, training.
This is where our own project pages put most of their words: the decisions, not the deliverables list. A buyer reading about a redesign wants to know why the hero changed, not that 'a new hero was designed'. You can see how we present our projects on our work.
How should you present case study results?
Present case study results as specific numbers with context: the metric, the before, the after, the timeframe and how it was measured. A single number without context invites doubt; the same number with a baseline and a period reads as evidence. Only publish results the customer has approved.
Lead with the one outcome in the headline, then add supporting results lower down. Mix hard numbers with qualitative changes the customer described, such as 'the sales team now sends the page instead of a deck'. If a result has caveats, like a change that coincided with a pricing update, say so. Honest caveats make the rest of the numbers more believable. For conversion results specifically, our guide to demo request conversion rate benchmarks helps you put a before-and-after number in context.
A hypothetical example: filling in the template
A hypothetical example, for illustration only: a B2B payroll startup's case study about a customer, a 200-person agency. Headline: 'How an agency cut payroll prep from two days to an afternoon.' Summary box: agency, 200 staff; challenge: manual payroll across three countries; solution: automated payroll with local compliance; result: monthly prep time reduced, approved by the customer. The problem section quotes the finance lead on the monthly scramble. The decision section explains they nearly stayed on spreadsheets because of switching risk, and what the migration plan included. The solution covers the three decisions that mattered. The results give the before, after and period. It ends with a quote and a 'See how it works for agencies' button.
What design choices make a case study page easy to read?
The design choices that make a case study page easy to read are a strong summary at the top, short sections with clear headings, results shown as large numbers, real screenshots, and a quote pulled out visually. The page should work for a skimmer in ten seconds and for a careful reader in five minutes.
Pros
- A consistent template makes every new case study faster to produce.
- Summary boxes and result stats are easy for buyers and AI engines to quote.
- A forwardable page helps a champion sell internally without you in the room.
Cons
- Rigid templates can make every story read the same. Let the strongest part of each story lead.
- Results need customer approval, which can delay publishing.
- Heavy visuals can slow the page, so optimize images and keep motion light.
End with one clear next step that fits the reader's stage, such as 'See pricing', 'Book a demo' or a link to a similar case study. If you add a form, keep it short; our guide to landing page form design covers how many fields to ask for. For SaaS teams, our SaaS customer story template adapts this structure for sales teams who send stories to prospects.
Where should case studies appear on the rest of the site?
Case studies should appear wherever a buyer needs proof of a specific outcome: as short summary cards on landing pages, beside related features, on industry pages, on pricing, and on demo pages. The full case study page is the destination; the cards are the routes in.
Link customer logos in your trusted by section to their case studies, and add a related case study card next to the form on your book-a-demo pages. If you're early and don't have customer stories yet, start with the honest alternatives in social proof for startups, and plan to collect the before-and-after data from your first customers.
