Disc Case Study Paragraph

---
name: disc-case-study-paragraph
description: Writes a Case Study Paragraph for a proposal, 120 to 180 words of challenge, action and result matched to this client's situation without bending the facts, a 40-word version, the permission status and results only as the past client approved them. Use for "run disc-case-study-paragraph", "case study paragraph", "add a case to the proposal", "relevant experience", "proof for this proposal", "short case for the RFP", "which past project fits", part of the Claude for Winning Proposals Pack by Polar Bear.
---

# Case Study Paragraph

## When To Use
The proposal needs proof a model cannot generate, and only your real work counts. A new prospect is asking, quietly, "have they done this before, for someone with our problem?" You have past work that fits and need it written short, honestly and in a form you are allowed to share.

## When Not To Use
If you do not yet know which proof the proposal needs, start with Win Themes. If you have no past work that honestly mirrors this client, say so in the Consulting Proposal and offer a smaller first phase instead of a stretched case.

## Inputs
- Your notes on the past project: the situation, what you did, what changed, in your words or the past client's
- The results as the past client approved them, and what they agreed to (named, anonymised, not asked)
- This client's situation in three lines, and where the paragraph sits in the proposal
If you have none of this, I run five short questions on the past project and mark the paragraph "first draft, permission not confirmed".

## Approach
Challenge, action, result is a practitioner convention, described here generically. The paragraph matches the prospect by selection, never by alteration: it chooses which true detail to lead with and says the rest less. The trap is the mirror, bending a past project until it describes one that did not happen. A prospect who asks one follow-up question about a bent case stops trusting the whole proposal.

## Workflow
1. Ask at most three questions: which past project you have in mind, what the past client agreed to (named and approved, anonymised and approved, or not yet asked), and what this prospect most needs to recognise.
2. Challenge, one or two sentences: the past client's situation by role and problem ("a past client's operations lead faced [problem]"). No size, sector or type unless the past client approved that detail and you insist on it.
3. Action, two or three sentences: what you did, specific, including the turn that changed direction. Name no past-client staff without permission.
4. Result, one or two sentences: only as approved, with base and period where the past client gave them. Without approval, a [placeholder] and "ask". A delivered piece of work with no measured outcome says what was delivered and stops.
5. Bridge, one sentence: what you would do the same way for this client, as an intent, never a promise of the same result.
6. Trim to 120 to 180 words, then write a 40-word version from the challenge and result sentences.
7. If permission is "not yet asked", draft a short request to the past client for you to send, stating exactly which words and figures would appear.

## Output Format
```markdown
# Case Study Paragraph
**Past project:** [internal name] | **Written for:** [prospect role and need] | **Date:** [date]
## Permission status
[Named and approved / Anonymised and approved / Not yet asked], confirmed by [past client role] on [date]
## Paragraph (120 to 180 words)
[Challenge] [Action] [Result as approved] [Bridge as intent]
## Short version (40 words)
[Challenge and result in 40 words]
## Sources
| Statement | Source | Approved for use |
|---|---|---|
| [result line] | [notes, email, date] | [yes, no, ask] |
## Permission request draft (if not yet asked)
[Short note for you to send, listing the exact words and figures]
## Decision
[You] confirm the permission status and the result line with the past client before [proposal send date].
```

## Done When
- Every statement traces to your notes and every result to the past client's approval
- The prospect's situation shaped the order of details, not the facts
- Both lengths are within their word limits and the permission status is stated

## Quality Bar
- Past client described by role and problem, never by size, sector or type unless approved
- One result with base and period, or none; never "results like these" or "typically"
- The bridge is an intent, never a promise of the same outcome
- Only real work, results as approved; Claude never invents a reference or a result

## Next
Run disc-ai-use-statement (AI Use Statement) to say plainly how AI is used in the work.

## About the makers

This pack is made by Polar Bear, a consultancy built by ex-McKinsey founders with a dream to make AI work for People, not instead of them. We help our clients build people systems and AI-first ways of working, and we run our own company on Claude. If your team has outgrown the self-serve version, message Pauline (linkedin.com/in/paulinebertry).