How to Draft Customer Case Studies

8 min read Guides

A practical guide to drafting customer case studies with an agent: interview questions, an outcome-led draft, fact-checking, and customer permission.

A customer case study is a short proof document built from one customer's real story: what they did before, what changed, and the measured result, told in their own words. Drafting one means catching a customer right after they get clear value, interviewing them about the before and after, and shaping their answers into a page a skeptical prospect will believe.

For a small team it is the one marketing asset that cannot be faked. A named customer with a confirmed number carries more weight than anything you write about yourself, and a finished study keeps working in sales conversations long after the hours it took to produce.

Why unwritten case studies quietly cost you

Every few weeks a customer hits a result worth telling. Without a process, the moment passes. The enthusiasm fades, the numbers get fuzzy, and by the time you ask for an interview the customer has moved on to the next problem.

The cost lands in two places. In sales, you keep repeating your own claims because there is no customer on record making them for you. And when a study finally does get written under deadline pressure, the shortcuts show: a paraphrased quote, a rounded-up number, a logo the customer never agreed to. A case study uses a real person's name, words, and figures, so a sloppy one damages the relationship it was meant to celebrate.

What the manual process looks like

Done by hand, a case study is a small project with seven steps:

  1. Notice that a customer hit a real result and ask them for an interview.
  2. Prepare questions that cover the before, the turning point, and the after.
  3. Run the interview, pressing gently for a hard number and lines worth quoting.
  4. Write the draft: a results headline, the customer's situation, the challenge, what they did, the results, and a pull quote.
  5. Check every number and quote in the draft against your notes.
  6. Send the customer exactly what will be published, including their quotes, how they will be named, and every metric, and wait for sign-off.
  7. Publish once they approve.

None of these steps is hard. Together they take enough hours that most teams do them rarely, and the checking steps are the first to get skipped, which is exactly where the risk lives.

What an agent can automate

Most of that project is preparation, drafting, and verification, which an agent can carry while the conversation and the final call stay with you:

  • Prepare the interview. From the customer and the value moment that triggered the study, the agent writes structured questions along a before, turning point, after, and so-what arc, designed to surface at least one hard number and two or three quotable lines. You run the conversation, and the agent makes sure it asks the right things.
  • Draft the case study. From the customer's answers and the account's usage, the agent writes the mini case study: a results headline, a customer snapshot, the challenge, the solution described as the customer's workflow rather than a feature list, two or three scannable result stats, a verbatim pull quote, and a soft call to action.
  • Assemble the permission request. Alongside the draft, the agent lists every quote attributed to the customer word for word, exactly how the customer will be named and described (person, role, company, logo use), and every metric to be published, so the customer can approve precisely what will appear.
  • Fact-check independently. A second agent checks the draft against the interview answers and the usage data: every number traces to something the customer confirmed, every quote is verbatim rather than paraphrased, nothing marked off the record leaked in, and the permission request is complete. It produces a go or no-go note, and a no-go goes back to the drafting agent with specifics.

What stays with you is judgment: the interview itself, the decision that this customer's story is worth telling, and the final approval.

The guardrails that make it safe

The hard rule in this process is that nothing publishes without permission. A case study borrows a customer's name and credibility, so the workflow treats permission as a gate, not a courtesy.

The gate has two layers. First, the editor agent's fact-check: an altered quote, an unconfirmed number, or a violated confidentiality note is an automatic no-go, and the draft cycles back until it is accurate. Second, a human approval step ends the workflow. It waits in your inbox with the draft and the permission request, and it asks you to confirm the customer has approved their quotes, attribution, and metrics (or to route the permission request to them first) before you sign off. Only after both the customer and you have approved does the case study count as publish-ready.

The agents never publish anything on their own. Their job ends at a verified draft and a permission request that makes it easy for the customer to say yes.

Set it up in Task Machine

The Customer case study drafter playbook installs the method above as working records in your workspace: the interviewer agent that prepares questions and writes the draft, the editor agent that fact-checks it, the team that holds them both, the two skills carrying the interview and writing method, and the workflow that ends in the customer-permission gate. Setup takes a few minutes. You need a Task Machine workspace and permission to install playbooks (workspace owners have it). No outside services need to be authorized, because the workflow runs on the interview answers and account details you bring to it.

1. Find the playbook

Open Playbooks in your workspace and search for "case study", or browse to the Growth category. The card lists what the playbook creates and the models its agents run on.

The playbook gallery with the Customer case study drafter card in the Growth category, listing two agents, one team, two skills, and one workflow

2. Preview what it installs

Preview & install opens the full contents before anything is created: the Case Study Interviewer, the Case Study Editor, the Case Study Team, the customer-interview and case-study-writing skills, and the drafting workflow that ends in the customer-permission and approval gate.

The Customer case study drafter preview listing both agents, the team, both skills, and the four-step workflow ending in the permission gate, with a Start setup button

3. Scope the first case study

Start setup asks for the story the workflow should start with. Customer name names whose story it is. Product or service names what they used, which shapes the challenge and solution sections. Measured results takes the confirmed outcomes the draft should lead with, one per line. Approval or confidentiality constraints captures the rules the permission request must respect, such as who signs off on quotes or which figures may not be published.

The setup form filled in for a design studio client: the customer name, the product or service, two measured results, and a note that the founder approves all quotes

4. Generate and review

Generate customized playbook bakes your answers into the agent instructions and the workflow prompts. The result comes back for review before anything is created. Read through the agent and workflow cards and confirm the customer details, the measured results, and the constraints appear where you expect them.

The review step showing the customized interviewer and editor agents, the team, both skills, and the workflow, with a banner confirming nothing has been created yet

5. Install

Install customized playbook creates everything in one step and lists what landed in your workspace. One follow-up arrives in your inbox: Start Customer case study drafter, which walks you through the value-event intake, the customer interview questions, the claim verification, the customer-permission gate, and your final approval before the publish-ready draft exists. There is no schedule behind this playbook. Each run is a deliberate act: whenever a customer hits a clear value moment, start the workflow again for their story.

The install confirmation listing the created agents, team, skills, and workflow, with a Playbook installed notice and the follow-up to start the first run

What good looks like

The playbook's own quality bar tells you whether a run worked:

  • The interview produced the raw material. A costed before-state, a concrete after-state with at least one hard number, the why-us moment, and two or three quotable lines the customer confirmed.
  • The draft is skimmable. A reader who only sees the headline, the two or three result stats, and the pull quote gets the whole story.
  • The permission request passes on the first read. Every quote verbatim, the naming exact, every metric one the customer already confirmed, so approval takes the customer minutes rather than a negotiation.

Common questions

Does the agent interview the customer directly? No. The agent prepares the questions and you run the conversation. The interview is a relationship moment with a customer who just got value from you, and the structured questions make sure that conversation surfaces a hard number and quotable lines without turning into an interrogation.

What if the customer will not share a specific number? An unconfirmed number never publishes. The interview technique is to ask an open question and then follow with "can you put a number on that?", because a figure like a task going from hours to minutes beats "much better". If the customer declines, the study runs on the concrete before-and-after change instead, and the fact-check keeps any implied figure out of the draft.

Can the agent publish the case study on its own? No. The workflow ends at a human approval step, and before that step the editor agent must issue a go note. Nothing counts as publish-ready until the customer has approved their quotes, attribution, and metrics and you have signed off.

What if the customer wants to stay anonymous? Put that in the approval and confidentiality constraints during setup. The permission request states exactly how the customer will be named and described, including role, company, and logo use, so an anonymized or role-only attribution is agreed in writing before anything is drafted for publication.

When is the right moment to run it? Right after a clear value moment, while the result is fresh and the customer can still put numbers on it. Waiting costs you both the enthusiasm and the precision, which is why the workflow is built to start from a specific value event rather than a calendar.

Put the work you just read about on rails

Join the waitlist and we will send early access when the first private beta spots open.

Private beta. We invite teams in batches and never share your email.