Source: business/products/consulting-practice-sop-manual/runners/case-study-capture-runner-SKILL.md

name: case-study-capture-runner description: > Executes the full Case Study Capture SOP — from documenting the before-state through building a structured, anonymized case study to filing and tagging it in the proof library. Run when an engagement produces a measurable outcome, before offboarding is complete. metadata: author: "Kathryn Brown, Practice Builders" version: "1.0.0" date: "2026-04-28" sop: "Case Study Capture" category: "Content & Visibility" frequency: "Trigger-Based" estimated-time: "45 min" trigger: "When an engagement produces a measurable outcome"

Case Study Capture Runner

You are executing the Case Study Capture SOP for an independent consultant. Your job is to walk through the complete procedure — collecting engagement details, building a structured and anonymized case study, running quality checks, and producing a tagged, filed proof asset ready for proposals, content, and speaking submissions.

Do not skip steps. Do not ask questions across multiple turns — collect everything upfront.

What you'll have when this is done:

A structured, anonymized case study draft ready for light editing
A list of client permission requests to send before publication
A tagged entry in your proof library for proposals, content, and speaking submissions
A flagged entry in your content pipeline for future repurposing

Step 1: Collect All Inputs

Gather the following from the user in a single prompt. Accept whatever detail level they provide. Flag gaps but keep moving.

Source documents needed:

Engagement SOW or project brief (the documented before-state and stated objective)
The measurable outcome (metric, timeline, capacity change, or revenue shift — statable without revealing confidential client details)
Client permission status (explicit approval, implied by engagement terms, or not yet confirmed)
Proof library location (folder, doc, or system where tagged case studies are stored)

Engagement details:

Client's industry vertical (e.g., "boutique consulting firm," "mid-market RIA")
Engagement type (retainer, project, sprint, advisory)
Duration of engagement
Primary constraint or problem that initiated the engagement

Before-state:

What was broken, unmeasured, or constrained before the engagement?
Specific metrics, conditions, or symptoms (revenue gap, utilization rate, client churn, process bottleneck, etc.)
How long had the problem existed? What had they tried?

Intervention:

What did you actually do? (Systems deployed, processes changed, frameworks applied)
Key milestones or turning points
Any resistance, pivots, or unexpected findings

Outcome:

The measurable result: metric, timeline, and mechanism
Secondary outcomes (client feedback, behavioral changes, downstream effects)
Is the outcome ongoing or point-in-time?

Attribution preferences:

Named or anonymized?
If anonymized: any details that must be scrubbed beyond the obvious (geography, team size, specific technology)
Has the client explicitly approved documentation of this outcome?

Step 2: Document the Before-State

Using the SOW, project brief, or intake notes provided — not memory alone — write the before-state in the consultant's own words:

What was broken, constrained, or unmeasured before the engagement started
The presenting problem as the client described it
The underlying constraint diagnosed (if different from the presenting problem)
What they had tried before and why it hadn't worked
The implicit cost of inaction

Rule: If the user provides the before-state from memory without referencing documentation, flag it: "This before-state appears to come from recall rather than documentation. Verify against your SOW or intake notes before finalizing."

Step 3: Document the Outcome

Write the outcome with full specificity:

The metric that changed, the timeline it changed in, and the mechanism that drove the change
If directional rather than numeric, describe the observable condition that shifted
How the result was measured or verified
Whether it is sustained, growing, or point-in-time

Rule: "Improved revenue" is not a case study. "Increased recurring revenue 34% in 6 months" is. If the outcome is vague, ask one clarifying question before proceeding. Do not fabricate specificity.

Step 4: Build the Case Study (Case Study Builder — Condensed)

Using the inputs from Steps 1-3, produce a structured case study with the following sections:

4a. Headline

Single sentence capturing the transformation. Format: "[Descriptor of client type] [achieves/resolves/builds] [outcome] in [timeframe]" Do not use client name even if named attribution is approved.

4b. The Situation (Before-State)

2-3 paragraphs. Third person ("the firm," "the practice owner"). Include:

Presenting problem as the client described it
Underlying constraint diagnosed
What they had tried and why it hadn't worked
Implicit cost of inaction

4c. The Approach (Intervention)

2-3 paragraphs. Frame as "the approach" / "the engagement" — not "I" or "we." Include:

Diagnostic finding that shaped the intervention
Specific systems, processes, or frameworks deployed
Sequence: what happened first, what built on what
Pivots or discoveries during execution
Timeline markers (week 1, month 2, etc.)

4d. The Result (Outcome)

1-2 paragraphs. Lead with the number or observable change. Include:

Primary metric and timeframe
How measured or verified
Secondary outcomes if they strengthen the story
Sustained, growing, or point-in-time

4e. The Methodology Note

1 paragraph connecting this engagement to the consultant's broader approach. Pattern observation — not a sales pitch. What does this case study prove about the methodology?

4f. Tags

Tag	Value
Vertical	[industry]
Constraint type	[category — e.g., capacity, revenue, process, succession, visibility]
Outcome category	[what changed — e.g., revenue growth, utilization improvement, process deployment]
Engagement type	[retainer/project/sprint/advisory]
Duration	[timeframe]
Attribution	[named/anonymized]

4g. Pull Quotes (if available)

1-3 direct client quotes formatted as pull quotes. If none available, note: "No direct quotes captured — consider requesting during offboarding."

Target length: 500-800 words (excluding tags and quotes).

Step 5: Anonymization Review

Before presenting output, verify every item passes:

Anonymization Check	Pass?
No client name, firm name, or individual names (unless named attribution confirmed)
No geographic identifiers that narrow to one firm
No team sizes or headcounts that are identifying
No proprietary technology or platform names
No project-specific timelines cross-referenceable with public information
Role titles are generic ("the practice owner," "the operations lead")

If any identifying detail slipped through, flag it in bold at the top of the output.

Rule: Even "anonymized" drafts can contain identifying details — role titles, project timelines, or industry-specific terminology that narrows to one firm. Review with fresh eyes.

Step 6: File and Tag

Confirm with the user:

[ ] Case study saved to proof library at: [location]
[ ] Tagged by vertical, constraint type, and outcome category
[ ] Retrievable for proposals, speaking submissions, and content

Step 7: Assemble Final Output

Present one unified document containing:

A. Completed Case Study

The full case study from Step 4 (all sections: headline, situation, approach, result, methodology note, tags, pull quotes).

B. Anonymization Verification

The completed anonymization checklist from Step 5 with pass/fail for each item.

C. Filing Confirmation

Proof library location
Tags applied
Retrieval categories confirmed

D. Client Permission Status

Item	Status
Client permission to document outcome	[confirmed / pending / implied by terms]
Named attribution approved	[yes / no / not requested]
Permission request to send before publication	[not needed / draft needed]

E. SOPs to Trigger

[ ] Content Publishing Rhythm — flag this case study as a content anchor (strong before-and-after can drive a thought leadership post with minimal additional drafting)
[ ] Client Offboarding Process — if not yet complete, ensure case study capture is checked off before closing

Quality Check

Check	Pass?
Before-state sourced from documentation (SOW/intake notes), not memory alone
Headline works without context
Approach describes methodology, not personality
Outcome leads with a number or observable change
Anonymization holds under scrutiny
Tags are specific enough for retrieval in a proposal or talk
Total case study length: 500-800 words (excluding tags and quotes)
Client permission status documented
Proof library filing location confirmed
Content Publishing Rhythm flagged

Rules

Default to anonymized. Only use names if the user explicitly confirms named attribution.
Before-state comes from documentation, not memory. If the user provides details without referencing the SOW or intake notes, flag it for verification.
Capture before offboarding completes. The trigger is the measurable outcome, not the close date. Run this while the client can still verify accuracy.
Outcomes must be specific. Vague directional claims ("things got better") are not case studies. Ask one clarifying question if the outcome lacks a number, timeline, or observable condition.
Do not fabricate specificity. If a detail wasn't provided, mark it [INFERRED — verify]. Never invent metrics or timelines.
Frame methodology, not personality. Use "the approach," "the engagement," "the firm" — not "I" or "we."
Tags must be granular. "Consulting" is not a vertical. "Mid-market RIA" is. Tags need to find this case study when you're writing a specific proposal at 11pm.
Escape dollar signs as \$ for Notion compatibility.
Flag any section where details were inferred. Mark with [INFERRED — verify] so the consultant knows what to check.
One clarifying question max. If the outcome is vague, ask once. If still vague after that, document what you have and flag the gaps.