mardab96 Won Deal to Case Study
Use this skill when
The results exist and the proof does not.
Almost every B2B company has this problem in the same shape: several customers are demonstrably happy, everyone agrees a case study would help, and nobody writes one, because writing one from scratch takes a week and interviewing the customer takes a scheduling miracle.
Most of the material is already in the CRM. This assembles a draft from it, marks every gap the customer needs to fill, and writes the email that asks them.
Required input
- The deal: what they bought, when, and what the situation was before.
- Whatever exists in writing: CRM notes, call transcripts, the original proposal, onboarding messages, support threads.
Strongly improves the result:
- any number they have said out loud, even approximately
- what they tried before you
- the internal objection they had to overcome
- who the champion was and what their role is
Analysis workflow
- Reconstruct the before state from the record: what was actually happening when they started looking, in specifics. This is the part that makes a case study readable and the part most drafts skip.
- Find the trigger. Nobody buys because of a slow-burning inefficiency; they buy in the week something forced the issue. Locate that week.
- Separate what you can evidence from what you would like to claim. Every number goes in one of two buckets: stated by the customer, or not stated. There is no third bucket.
- Reconstruct what changed, in their operational terms rather than in product features.
- Mark every gap where the story needs the customer's own words, and be specific about which sentence you are asking them for.
- Draft the case study with the gaps visible as placeholders, so nobody accidentally publishes an inference as a quote.
- Decide what the story is actually about before writing a word of it. A case study about your product is a brochure; a case study about a company that had a problem and now does not is something a stranger reads to the end.
- Write the permission email. It is short, it says what you will publish, it offers approval before anything goes live, and it makes declining easy.
- Note who at your end owns chasing the approval, because this is the step where case studies die.
Decision rules
- Nothing gets published without the customer's approval. This is not a style preference; using a company's name and results without consent is a legal and relationship risk.
- A number that the customer did not say is not their number. Model numbers can appear, labelled as estimates, or not at all.
- If the CRM record is too thin to reconstruct a before state, say so and write the interview questions instead of a draft.
- An anonymised case study is a real option, and often the fastest one when a customer's legal team is slow.
- Do not build the story around your product. The buyer reading it is looking for their own situation, and the product is the least interesting part.
Output format
The draft
Situation, trigger, what they tried, what changed, and where they are now. Every unverified claim visibly marked. Every place needing a quote marked as a gap.
Evidence table
| Claim | Source | Verified | Needs customer confirmation |
|---|
What to ask the customer
Five questions maximum, each aimed at a specific gap in the draft, written so they can be answered in one sitting.
The permission email
Ready to send. Names what you want to publish, offers approval, gives an easy no.
The anonymised version
One paragraph showing what the story looks like without the name, for when approval is slow or refused.
Practical example
A closed-won deal from four months ago. The CRM has the discovery notes, the proposal and an onboarding thread.
The notes reconstruct a clear before state: two people manually reconciling orders across three systems every Monday. The trigger is in the discovery notes, a missed month-end close that a board member noticed.
There are two numbers in the record. One is theirs: "about a day and a half a week" from the discovery call. The other is yours: a projected saving from the proposal, which does not go in the draft at all.
The gaps are marked: what Monday looks like now, and whether the month-end problem recurred. Those become two of the five questions. The permission email asks for fifteen minutes or a written reply, whichever is easier, and offers full approval rights before publication.
Guardrails
- Do not publish, send or share anything. This produces a draft and an email.
- Do not invent quotes. Ever. A plausible quote attributed to a real person is fabrication.
- Do not use a customer's name, logo or results without documented permission.
- Do not present your own projections as their outcomes.
- Do not include commercially sensitive details, pricing or named individuals without checking what the contract allows.