Case studies that close: a structure for B2B tech

Most B2B tech case studies do not lose deals. They just fail to help win them. The PDF gets uploaded to the website, mentioned once in a sales pitch and never opened again. The reason is rarely the client story. It is the structure. Buyers want a specific shape of evidence at a specific moment in their evaluation, and most case studies do not deliver it.

We have written case studies for managed service providers, SaaS vendors and ERP consultancies, including work for Littlefish, Codestone and Aspire Technology Solutions. The ones that get used in pitches and shared in pipeline emails follow the same structure. The ones that sit unread tend to share a different set of mistakes.

The two jobs a case study has to do

A case study has to do two things at once. It has to convince a buyer who has never heard of you that you can be trusted with their problem, and it has to give your sales team a piece of paper they can hand over with confidence. Those jobs sound similar, but they pull the writing in different directions.

The buyer wants a story that mirrors their situation. The sales team wants a story they can scan and quote from. Get the balance wrong and the case study reads like a press release, full of warm sentiment and short on detail, or like an internal report, dense with figures and impossible to skim. The case studies we write are designed to be read three ways: skimmed in 30 seconds, read properly in three minutes and quoted from in a pitch.

The structure we use

After writing a few hundred of these, we have settled on a structure that works across most B2B tech categories. The order matters.

1. Headline. A single sentence that names the client, the outcome and the metric. Not “Acronyms IT Support partners with us” but “How Acronyms IT Support cut average ticket response time from 41 minutes to 9”.
2. Snapshot box. Industry, size, the problem in one line, the headline outcome in numbers, project length. Buyers scan this first.
3. The situation. Two or three short paragraphs on what was happening before. What was breaking, what had been tried, what was at stake. This is where buyers decide whether the story is relevant to them.
4. The decision. Why the client chose you, in their words where possible. Avoid generic praise. Specifics like “we needed someone who could run a hybrid Azure and on-premise migration without taking the warehouse offline” are what land.
5. The work. What you actually did, in plain English, with enough technical detail that an IT director would believe it. This is the section most case studies skip and most buyers care about.
6. The outcome. Numbers, then context. “Ticket response time fell from 41 minutes to 9, freeing the internal team to focus on a back-office migration that had been parked for two years.”
7. A quote. One quote, late in the piece, from someone senior. Not stitched together from three emails. A real quote.
8. What is next. A short paragraph on the ongoing relationship. Buyers want to know the work did not end at go-live.

The whole piece runs to 700 to 1100 words. Longer than that and people stop reading. Shorter and the depth disappears.

Write the situation in the buyer’s language

The “situation” section is where most case studies miss. Marketing teams often summarise the problem in the language the vendor uses internally. The buyer reading the case study uses different language. They do not search for “managed XDR services”. They search for “we keep getting phishing emails through”. The situation section should sound like a buyer describing the problem to a colleague, not a vendor describing it in a deck.

When we interview clients for case studies, we lean hard on this. “Tell me what was actually breaking. Tell me what your team complained about on a Monday morning.” The verbatim phrases that come out of those interviews end up in the situation section, almost unedited, because they match the language the next buyer will use to find you. We’ve shared the actual scripts we use in customer interview templates.

Numbers, but with context

A metric on its own is not evidence. “Reduced ticket response time by 78%” sounds impressive until the reader notices there is no baseline, no time frame and no scope. We push for three things on every metric: the before, the after and the period. Then a sentence of context that explains why it mattered. “Ticket response time fell from 41 minutes to 9 over the first six months, which let the internal team stop running on adrenaline and start planning.”

Where direct metrics are hard to get (because the client cannot share them, or because the engagement is too new), we use proxy evidence. Number of users supported, scale of the migration, complexity of the integration, length of the relationship. Buyers can read between the lines.

Make the case study findable and useful

A case study only earns its keep if it is read by the right people. We make sure every one we publish has a clean URL, schema markup, a meta description that works in search and a clear path from the homepage and relevant service pages. The technical detail is in our wider notes on schema markup for SaaS websites and internal linking for tech sites.

We also build sales enablement assets out of every case study. A one-page PDF for sales, a short LinkedIn post, a quote card for the social team and a section in the next pitch deck. The case study is the primary asset, but the value comes from how many places it shows up. Our piece on repurposing technical content walks through the workflow we use.

Get the legal sign-off in advance

The single biggest reason case studies stall is legal review. Clients agree in principle, then the draft goes to their internal team and disappears for six weeks. We avoid this by building approval into the process from the start. We send a short approvals brief at the kick-off, agreeing what is on the record, who needs to sign off and what the timeline looks like. If specific numbers cannot be shared, we agree which ranges or proxies can. By the time the draft is ready, the path through legal is already mapped.

Refresh the case study library on a schedule

Case studies age fast in tech. A 2023 piece about a cloud migration starts to look stale by 2026. We schedule an annual review of every published case study and ask three questions: is the client still happy to be referenced, are the numbers still representative and is the technology stack still current. Pages that fail any of those get refreshed, replaced or quietly retired.

If you have a back catalogue of case studies that nobody reads, or a great client engagement that has never been written up, drop us a line and we will share what we have seen. Our content marketing service covers the interviewing, writing and approvals workflow if you would rather hand the whole thing over.