How to write a case study (with interview questions and an example)

A case study is a short, true story about one customer: the problem they had, what they did about it with your help, and what changed, backed by numbers and the customer's own words. To write one, pick a customer with a result you can measure, interview the person who lived with the problem for 30 to 45 minutes, and write it in this order: a headline that states the result, a summary box, who the customer is, the challenge, the decision, the rollout, the results, and what comes next. Get written approval before anyone else sees it. A complete example, a plumbing company and its dispatch software, is below.

This guide covers the customer case study used in marketing and sales. If a professor assigned you one, the section on academic case studies explains how those differ.

What a case study has to prove

Case studies get read late. The reader has a shortlist, a budget and someone to convince, and wants to know one thing: did a business like mine get the result you promise? Sales teams send them after a demo. Buyers forward them to the colleague who has to sign off.

So the piece has two jobs. It must be specific enough that the right reader recognizes their own situation, and credible enough that a skeptic believes the outcome. Concrete detail does both. "A 26-person plumbing company in Columbus, Ohio" speaks to a plumbing company owner in a way "a leading home services provider" never will, and "3.1 to 3.9 jobs per technician a day" survives a skeptic where "dramatically more productive" does not.

Case study format, section by section

The summary box does the job a nut graf does in a newspaper story: it tells a reader in a few seconds why the rest is worth their time. Some readers will see only the headline and the box, so both must make sense alone.

Many templates skip the decision section, yet your reader cares about it most, because it is the step they are on: comparing options and wondering what the catch is. Say what else the customer considered, in general terms ("two other scheduling apps and a bigger whiteboard"), what objection they had to get past, and how it was resolved. Naming competitors invites a dispute you don't need.

Choose the right customer

Your happiest customer is not always your best story. Look for these four things:

• A change you can measure. Hours, dollars, days, error rates, calls, sign-ups. If nobody can name a number, the story will rest on adjectives.
• A before they still remember. Three months to a year after the switch is a good window: long enough for results to show, recent enough that the old way is vivid.
• A reader you want more of. The customer should look like the buyers you are trying to reach, by industry, size and problem. A famous logo whose situation matches nobody else's makes a weak case.
• A champion who can get it approved. One person willing to give you an hour, who knows who signs off.

Candidates turn up in support tickets that end in thanks, in renewals and upgrades, in your own usage data, and in the accounts your sales team keeps mentioning on calls. Ask the customer success team which customers would pick up the phone.

Settle permission before you book the interview. Many customer contracts limit how a vendor can use the customer's name and logo, and larger companies send every case study through communications or legal. Find out who approves, how long it takes, and whether the name, logo and numbers can appear. If the answer is no, an anonymous version ("a 40-location dental group in Texas") is still worth writing, though it persuades less.

How to interview the customer

Do your homework first, so the call is spent on what only the customer knows. Pull the account history: start date, plan, support tickets, usage. Write down the numbers you suspect and need confirmed, and send three or four questions ahead so they can look up figures before you talk.

Interview the person who lived with the problem every day, not only the executive who signed the contract. One senior quote is useful, but the detail comes from whoever did the work. Book 45 minutes and plan to use 30. Record the call, and ask for permission on the recording, since some states and countries require everyone's consent. Take notes in a fixed format, such as an interview notes template, so the quotes are easy to find later.

Ask for scenes, then numbers

• Ask about a specific moment. "Walk me through the last time that went wrong" gets a story. "What were your challenges?" gets a list of abstractions.
• Follow each claim with "Roughly how many?" or "How do you know?" A dispatcher who says "we were always behind" can usually tell you how many calls a day went unanswered.
• Ask what they tried before. A spreadsheet, a new hire, another vendor, doing nothing: the failed attempts show the problem was hard.
• Don't lead. "Wasn't setup easy?" gets a yes you can't quote. "What was setup like?" gets a sentence you can.
• Let silence sit after an answer. The best sentence often comes second, once the prepared answer is out of the way.

When the customer has no numbers

Plenty of customers never measured the before. Ask them to estimate a typical week then and now, and label the result honestly ("the team estimates"). Pull figures from your own product data, with their permission. Or count something visible: calls logged, tickets opened, invoices sent. Give every number a baseline and a timeframe, and be wary of percentages on small bases. Going from two leads a month to six is "200% growth," which sounds bigger than it is. Say two to six.

How to write a case study

1. Transcribe and mark up the interview

   Get a transcript and highlight every number, every specific moment and every sentence you might quote. Tag each one with the section it belongs to: before, decision, rollout, after.

2. Write the result as one sentence

   Who, what changed, by how much, in how long: "Marlow Brothers fit 26% more jobs into each technician's day within six months." This sentence becomes the headline and the top of the summary box. If you can't write it, go back for numbers before you draft anything.

3. Draft the challenge as a scene

   Open on a moment from the interview, then give its cost. Keep your product out of this section entirely. The reader should recognize the problem before they hear about any solution.

4. Tell the decision honestly

   What they considered, the objection, what tipped it. One real doubt, resolved, does more for credibility than a page of praise.

5. Describe the rollout in concrete terms

   How long it took, who did what, what was hard. Name the one or two features that mattered to this customer. The full tour belongs on your product page.

6. Write the results as before-and-after pairs

   Each number gets its baseline, its timeframe and its source. Then add one change that isn't a number, the thing the customer mentioned with feeling.

7. Write the headline and summary box last

   The headline names the customer and the result. The box lists customer, challenge, solution and results. There is more on headline craft in how to write a headline.

8. Tidy the quotes and send it for approval

   You may cut filler, false starts and repetition. You may not change the meaning or add words nobody said. Send the full draft with a date for comments and a short list of what you need confirmed: facts, quotes, logo use.

Match quotes to your company's style guide for numbers and titles, but leave the speaker's phrasing alone. A quote should sound like the person read aloud, not like your brand's tone of voice.

A complete case study example

Here is a full case study built from the steps above, at about 600 words. Everything in it is invented, including the software company.

What makes it work

• The headline gives a number and who got it. An owner of a small trade business knows within seconds whether this is for them.
• The challenge is a scene, the whiteboard at ten in the morning, before it becomes a statistic.
• The decision names the real objection (technicians who would not use an app) and shows how the pilot answered it. That is the paragraph the next skeptical owner needs.
• The product appears in the middle, with the one feature that mattered to this customer and an honest rough first week.
• Every number has a before, an after, a timeframe and a source.
• The most memorable line is about lunch. One human detail makes the numbers easier to believe.

Common mistakes, side by side

Here are four lines from the example above, next to the versions most first drafts contain.

• The product is the hero. If your product's name is the subject of most sentences, rewrite until the customer is.
• Quotes nobody would say. People don't talk in brochure copy. Quote the sentence they said with feeling, trimmed.
• No friction anywhere. A rollout without a single problem reads as fiction. One honest difficulty, and how it was solved, makes the rest believable.
• Writing for the customer instead of the reader. The customer approves it; the prospect reads it. Cut internal project names and in-jokes.

Academic and business-school case studies

In a classroom, "case study" usually means one of three things. A research case study examines one case in depth (a person, an organization, an event, a place) to answer a research question, and is written like a research paper: introduction, literature review, method, findings and discussion, with an argument for why you chose that case. A teaching case is a narrative built around a decision. Harvard Business School describes its cases as 10 to 20 pages, written from the viewpoint of a real person leading a real organization, each ending in a key decision. A case analysis is a student's answer to a teaching case: the problem, the options, a recommendation and the reasoning.

Your instructor's format overrides any general guide, including this one. The interviewing advice above still applies to research case studies: ask for specific moments, check every number, and keep your subject's words as they said them.

Writing case studies in Strokes

Each case study collects a pile of material: a transcript, account notes, drafts, the customer's edits and the approved version. In Strokes, a project folder per customer keeps them together as files on your machine. Add the transcript to a chat with the AI Assistant and ask it to list every number and who said it, or to sort quotes into before, decision and after. Then check each one against the recording, because transcripts mishear figures. Select a loose paragraph and press ⌘K to tighten it.

Version history keeps the draft the customer approved, so you can see exactly what changed if their legal team asks later. Export to PDF or Word for the approval round and the sales team's one-pager. To skip the blank page, download the case study template as Word or Markdown and import it.