How to Prompt AI to Write a Case Study
A two-pass prompting method that forces AI to extract a real number and a real quote before it writes a single word of your next case study.
Most AI-written case studies read the same: a customer “streamlined operations” and saw “significant improvement,” with no number attached to either claim. If you are working out how to prompt AI to write a case study that a sales team will actually use, the fix is not a longer prompt or a fancier template. It is a two-pass method: run one prompt that extracts the quantified outcome and the specific obstacle as a structured brief, then run a second prompt that writes the case study from that brief alone. Skip the extraction pass and you get vague praise. Run it first and you get proof.
Why “increased efficiency” is a symptom, not a result
Ask a model to write a case study straight from a call transcript and a company name, and you will get some version of “increased efficiency” or “streamlined workflows.” Those phrases surface because the model was never handed a number to anchor to, so it pattern-completes sales language instead of reporting a result. The same failure shows up in a SWOT analysis prompt that fights the same vagueness problem: ask for “weaknesses” with no supporting detail and you get a list of platitudes instead of anything specific. A model cannot invent a number that was never in its input. If the prompt does not force the number out first, the finished draft will not have one either.
How to prompt AI to write a case study: the two-pass method
This split follows the prompt engineering framework this builds on: separate the thinking step from the writing step so the model is not reasoning and performing at the same time. Pass one is pure extraction. Feed it the raw material, a call transcript, an email thread, or the account manager's Slack recap, and have it pull exactly four things: the customer's specific starting problem, the quantified before-and-after metric, the timeframe, and one usable quote. Pass two takes that structured brief, never the raw material, and writes the narrative from it.
Pass one: the extraction prompt
Here is the extraction prompt we ran against real call notes, unedited:
“Read the attached call notes between our team and Briarwood HVAC, a 42-person HVAC company using Fenwick Ops for daily technician scheduling. Extract only: (1) the specific operational problem they had before using the product, in one sentence, (2) the single clearest quantified metric that changed, with the before and after numbers, (3) the time period over which that change happened, and (4) one direct quote from the customer that could run as a headline. If any of the four items is not explicitly stated in the notes, write 'NOT FOUND' instead of guessing. Return the four items as a labeled list and nothing else.”
The output from that prompt, run against a real transcript, looked like this:
Problem: Dispatchers spent close to 45 minutes every morning manually re-routing technicians around overnight cancellations and no-shows, which pushed the first two appointments of the day late almost without fail.
Metric: On-time arrival rate rose from 68% to 94%.
Timeframe: 90 days after rollout.
Quote: “We used to lose the first hour of every day just fixing yesterday's schedule. Now the schedule fixes itself before the dispatcher's coffee is cold.”, Dana Reyes, owner, Briarwood HVAC.
Pass two: the writing prompt
Pass two uses the same shape as a similar structured-extraction-then-write approach for status reports: never let the model narrate off the raw notes, only off the distilled brief. The writing prompt was this:
“Write a 220-word customer case study using only the four facts below, nothing else. Open with the quantified result, not the company name. Use the customer's exact words for the pull quote, do not paraphrase it. Structure: one-sentence result headline, two sentences of before-state context, three sentences on what changed operationally, the quote, and a one-sentence current-state close. [Problem / Metric / Timeframe / Quote pasted here]”
Before and after: the same customer, two case studies
A single-pass prompt like “write a case study about Briarwood HVAC using Fenwick Ops” produces something like this:
Briarwood HVAC has seen great success using Fenwick Ops to improve their scheduling process. Since adopting the platform, dispatchers have noticed a real improvement in day-to-day operations, and technicians are able to complete their routes with less friction. Briarwood HVAC continues to rely on Fenwick Ops to keep operations running well.
The two-pass version, built from the extracted brief, reads like this instead:
Briarwood HVAC's on-time arrival rate jumped from 68% to 94% in 90 days, without hiring another dispatcher. Before Fenwick Ops, the team spent the first 45 minutes of every shift manually re-routing technicians around overnight cancellations and no-shows, which meant the day's first two appointments ran late almost every time. Fenwick Ops now re-sequences the day's route overnight, so dispatchers start the morning with a schedule that already accounts for changes instead of one they have to fix by hand. “We used to lose the first hour of every day just fixing yesterday's schedule,” says owner Dana Reyes. “Now the schedule fixes itself before the dispatcher's coffee is cold.”
A reusable AI case study template for the extraction pass
The four-field brief above works as a reusable ai case study template for any customer, not just this one: problem, metric, timeframe, quote. Save it as a snippet and swap in new call notes each time. This matters most once you are past your first few customers. If you are at the point of turning a working side project into a real subscription business, a handful of specific, numbers-backed case studies do more for signups than another paragraph of feature copy, because a prospect trusts a dispatcher's actual words more than your product description.
Where the b2b case study prompt method breaks
This b2b case study prompt method assumes a hard number exists somewhere in your notes, and sometimes it does not. If the customer's win is qualitative, faster onboarding, less frustration, a calmer team, do not let the model invent a percentage to fill the gap. Change the extraction prompt to ask for a proxy metric instead: number of support tickets before and after, headcount that did not need to grow, or hours per week reclaimed by a specific role. If even a proxy is not in the notes, the honest move is to write the case study around the quote and skip the numbers entirely rather than fabricate one.
Frequently asked questions
What's a good prompt for a customer success story if there's no hard metric?
Ask the model to extract a proxy metric instead of a percentage, such as ticket volume, response time, or headcount avoided, and if none exists in your notes, write the story around the direct quote and skip the numbers rather than let the model invent one.
How long should an AI-written case study be?
180 to 300 words for a webpage or one-pager. Anything longer usually means the writing prompt did not have a tight enough structure, not that the story needed more space.
Can I use the two-pass method for a short testimonial instead of a full case study?
Yes. Run the same four-field extraction, then ask for a two-sentence testimonial instead of a 250-word narrative. The extraction pass does not change, only the length of pass two's output.
What if the customer's own quote is bland?
Ask a follow-up question instead of asking the model to punch up the quote. A model rewriting a customer's words to sound better is the fastest way to end up with a testimonial that reads like marketing copy instead of a real person.
How did this land?
About the author

Developer Advocate
Steve builds something with Swarmz every week and writes up what worked, what broke, and what he'd do differently. Tutorials and hands-on guides are his lane.


