win-story-brief
Paste into Claude Code, Claude.ai, the desktop app, or the browser extension — ⌘/Ctrl+V. ✓ Copied. Switch to Claude and paste — ⌘/Ctrl+V.
Win Story Brief
Produce a concise internal win story that captures why RBA won the deal, what was delivered, and how to position this engagement in future proposals and capability conversations. Designed for speed — run immediately after close while the team's knowledge is fresh.
When this skill applies
- Project has just closed, gone live, or entered hypercare
- A pitch, proposal, or capability conversation is coming up and the team needs a quick proof point
- You want to capture knowledge before the team disperses to new projects
- BD or practice lead is building a sector or platform capability deck
Skip for: client-facing publication → case-study-draft; award nominations →
award-submission-writer; partner renewal evidence → partner-evidence-package.
Inputs
| Parameter | Required | Default | Notes |
|---|---|---|---|
project-notes-or-retro-file |
Yes | — | File path to retro, PM notes, SOW, or inline description |
--project |
No | inferred | Project name for the output header |
--sector |
No | inferred | Client sector (shapes positioning advice) |
--platform |
No | auto-detect | Platform adapter for technical context |
--format |
No | brief |
brief = 1–2 page markdown; deck-notes = bullet-form for slide notes; both |
Workflow
Step 1 — Ingest
Read all provided files. Extract the following (if not present, note as "unknown" — do not pause for missing internal-only details the way you would for a client-facing draft):
- Why RBA won — what differentiated RBA in the selection process?
- What was delivered — platform, scope, key capabilities, team size
- What went well — 2–3 delivery highlights worth repeating on future projects
- What was hard — 1–2 honest observations (for internal use only — not for client sharing)
- Key metrics — whatever is available; directional is fine for internal use
- Client relationship health — is there expansion or referral potential?
Step 2 — Draft the win story
Produce the brief in the following structure:
Header block
Project: [Name]
Client: [Name (internal use — confirm external sharing separately)]
Sector: [sector]
Platform(s): [platforms]
Scope: [1-line description]
Duration: [months]
Team: [RBA headcount]
Closed: [month/year]
Why we won (internal — 100–150 words)
Honest account of the competitive differentiators. What did the client say? What did we do in the pitch or discovery that set us apart? Be candid — this section is for internal use only and should not appear in the client-facing case study without significant editing.
Good patterns:
- "We were the only agency that came to the pitch with a working XM Cloud demo built on the client's own content."
- "The discovery session surfaced a content governance problem the client hadn't articulated — our proposal solved it; the competitors didn't mention it."
- "Price was a factor, but the client said our team's Optimizely certification depth was the deciding factor."
What we delivered (150–200 words)
Plain-language description of the engagement scope and key deliverables. Written for a colleague who needs to understand it well enough to reference it in a proposal — not a technical spec.
Include:
- What the client's situation was before we started
- What we built, migrated, or configured
- Key technical decisions and their rationale (in 1 sentence each)
- Delivery model notes (fixed-price / T&M; sprint cadence; remote vs. on-site)
Results snapshot (50–100 words)
The 3–5 metrics available at time of writing. Directional language is acceptable for internal use when specific numbers are not yet confirmed. Label any estimated or unconfirmed figure:
- Page load time: ~50% improvement (Lighthouse; to be confirmed post-hypercare)
- Content authors trained: 42 in week 1 — zero escalations
- Go-live date: on time (against a 9-month estimate; delivered in 8.5 months)
- [ESTIMATE] Infrastructure cost saving: $120–150k/year (based on Azure cost modelling,
not yet confirmed by client finance team)
How to position this (internal — 100–150 words)
Sales and BD framing for proposals. Answer:
- Which prospects / sectors is this most relevant for?
- What capability does it demonstrate? (e.g. "our ability to deliver complex multi-brand XM Cloud programmes in regulated sectors")
- What objections does it address? (e.g. "clients worried about migration risk: this project had zero content loss across 14,000 items")
- What is the best version of the headline metric for a proposal?
- Should this feed into any certification evidence or award nomination?
What was hard (internal only — 50–100 words)
Candid observations for the delivery practice and future project teams. This section must be
clearly marked [INTERNAL ONLY — NOT FOR CLIENT SHARING].
Examples:
- "Third-party API latency was underestimated in discovery — added two sprints. Build a longer integration buffer into estimates for this sector."
- "Client stakeholder turnover mid-project delayed sign-off by three weeks. Agree escalation paths upfront in the SOW."
Relationship and expansion signals (50–75 words)
- Is there a managed services or retainer conversation underway?
- Did the client reference us to another division or organisation?
- Is there a logical next phase (personalisation, commerce, international rollout)?
- Should BD pursue this client for a reference, an award nomination, or a partner-programme customer reference?
Step 3 — Deck notes format (when --format deck-notes or both)
Produce a condensed bullet-form version for slide notes:
WHY WE WON
• [Differentiator 1]
• [Differentiator 2]
WHAT WE DELIVERED
• [Platform + scope in 1 line]
• [Key capability 1]
• [Key capability 2]
RESULTS
• [Metric 1]
• [Metric 2]
• [Metric 3]
POSITIONING ANGLE
• Best for: [sector/use-case]
• Headline metric: [strongest single number]
• Addresses objection: [objection + counter]
Step 4 — Output
Deliver the requested format(s). Add a header note:
[INTERNAL USE ONLY — Contains unconfirmed metrics and candid delivery observations.
Do not share with clients or include in marketing materials without editing through
the case-study-draft workflow and obtaining appropriate approvals.]
Recommend next actions:
- Run
case-study-draftto produce a client-facing version when metrics are confirmed - Run
partner-evidence-packageif this project qualifies as partner-tier evidence - Run
award-submission-writerif the project is a strong award candidate (see criteria in that skill's reference.md)
Technical details
- Plugin
- case-study-writer
- Author
- Dakota Smith
- Skill name
win-story-brief- Maturity
- experimental
- Security review
- No security review
- Owners
-
- business-development
- strategy
- Argument hint
<project-notes-or-retro-file> [--project <name>] [--sector <sector>] [--platform sitecore|optimizely|umbraco|azure|composable] [--format brief|deck-notes|both]- Allowed tools
-
ReadWriteEditBash(find *)Bash(ls *)
- Source
plugins/case-study-writer/skills/win-story-brief/SKILL.md
Edit this skill on GitHub — opens GitHub's web editor. No git knowledge needed.