A case study brief is the internal document that ensures your marketing team, subject-matter experts, and client align on story, scope, and approval before drafting. This walkthrough covers what belongs in each section of the brief, how to structure interviews and fact-gathering, and how to turn the completed brief into a publishable case study.
Most teams jump straight into client interviews and end up circling back for missing approvals or clarifications. The brief is the contract between you and the client about what this case study will cover. Start by documenting the project name, the client contact who will approve the final piece, and whether the company name can be used or if the case study must be anonymized. In Canada, note any bilingual requirements early: does the client expect a French version for Quebec audiences, and if so, who will translate technical terminology? Capture the intended distribution channels—website, sales deck, trade show handout, LinkedIn—because scope affects length and depth. If the client sells into government or regulated sectors, flag any procurement-sensitivity around pricing or vendor selection details. Lock this metadata down in the brief so the interview stays on substance, not administrative back-and-forth.
This section of the brief articulates what problem the client faced before engaging your product or service, and why it mattered enough to justify change. Avoid vague phrasing like business growth or efficiency gains. Instead, specify the operational constraint: were they manually reconciling invoices across three provinces, losing qualified leads because response time exceeded two days, or unable to track inventory in real time across warehouses? Include the timeline context—how long had the problem existed, what triggered the search for a solution, and what alternatives they evaluated. Mention any Canadian-specific friction: interprovincial shipping complexity, CRA reporting overhead, or difficulty finding vendors with local support in both official languages. Capture direct quotes from your pre-interview if possible, because lived frustration is more credible than paraphrased pain points. This brief section becomes the setup for your published case study, so make it concrete enough that a reader in the same industry recognizes their own situation.
Document exactly what you delivered: the platforms or services deployed, the team size and roles, the phases of the rollout, and the duration from kickoff to go-live. If the project involved third-party integrations—payment gateways, CRM sync, API connections—list them by name so the reader understands technical scope. Include any client-side responsibilities: did they provide historical data, assign an internal project lead, or conduct user acceptance testing? Note milestones and any mid-project pivots. If the original plan was to launch in Toronto but expanded to Montreal and Vancouver after initial success, that sequence demonstrates scalability and should appear in the brief. For Canadian projects, mention any localization work: bilingual user interfaces, CAD-specific tax logic, or compliance with provincial privacy rules. Avoid presenting the implementation as frictionless; if you encountered a challenge—data migration errors, stakeholder alignment delays—note it here so the case study can show problem-solving, not just a clean handoff.
This is where you reconcile ambition with approval. List every outcome the client is willing to share: time saved, error reduction, revenue attribution, customer satisfaction scores, process automation percentages. Be explicit about what is off-limits. Many clients will not disclose absolute revenue, margin, or headcount, but may allow directional language or percentage improvements over a baseline period. If the client cannot share quantitative metrics, pivot to qualitative wins: faster onboarding, easier compliance audits, stronger cross-department collaboration. Specify the measurement window—did results appear within the first month, or did you track performance over a quarter? Clarify attribution: if multiple initiatives ran concurrently, can you isolate the impact of your work, or is the outcome part of a broader transformation? For Canadian businesses, note whether results held across regions or showed variance between English and French markets. Capture exact phrasing the client approves for metrics so your draft does not trigger a revision cycle over a number they never agreed to publish.
Identify who will be quoted by name and title in the published case study. Ideally this is a decision-maker who experienced the problem firsthand and can speak to the selection process and outcome. If the client prefers anonymity, decide whether you will use a job title without a name, or omit attribution entirely. During the interview, ask open-ended questions that yield usable quotes: What was the turning point in choosing this solution? What surprised you during implementation? What would you tell a peer considering the same move? Record the conversation and transcribe key segments verbatim, because paraphrased quotes lose texture. Flag any statements that might require legal or compliance review—especially if the client mentions competitors, regulatory concerns, or internal politics. In Quebec or bilingual organizations, confirm whether the spokesperson will provide quotes in both English and French, or if translation is your responsibility. Store approved quotes in this brief section with explicit permission to publish, so your draft is not later challenged on what was or was not said on the record.
List what imagery, screenshots, logos, or charts the client will provide, and what must be redacted or anonymized. If you plan to include interface screenshots, confirm that no proprietary data, customer names, or internal process labels appear. For anonymized case studies, decide early whether you will blur company branding in visuals or replace real data with representative placeholders. Note any competitor mentions that must be scrubbed: if the client switched from a named incumbent platform, can you reference it, or must the case study say only previous solution? Canadian considerations include whether the client is comfortable with geographic identifiers—some B2B firms avoid naming their city to reduce competitor targeting. If the case study will appear in a sales deck shown to prospects in the same vertical, confirm the client is comfortable with that level of exposure. Capture these constraints in the brief so your designer and writer do not produce assets that require last-minute rework or client pushback.
Once the brief is approved, it becomes the outline for your case study. The challenge section maps to the introduction, the solution section becomes the methodology or approach, the outcomes section drives the results narrative, and the quotes provide voice throughout. Assign a writer who can translate the brief into narrative without inventing details or embellishing metrics. Use the brief as a fact-check reference during revisions: if the client questions a claim in the draft, you can point back to the approved language in the brief. If new information surfaces during the drafting phase—an additional stakeholder wants to be quoted, or the client realizes a metric was calculated incorrectly—update the brief first, get written approval, then revise the draft. This discipline prevents scope creep and ensures the published case study reflects only what the client explicitly endorsed. For bilingual projects, translate the brief before drafting in French so terminology and messaging stay consistent across languages. The brief is not a one-time exercise; treat it as the single source of truth that governs every subsequent draft, design iteration, and approval round.
The brief is the internal planning document that captures approvals, scope, metrics, and narrative framing before any writing begins. The published case study is the final narrative piece—often structured as challenge, solution, results—that goes on your website or into sales materials. The brief ensures alignment so the published version does not surprise the client or require major revisions.
Yes. Anonymized case studies still require a brief to lock in what can be shared, what must be redacted, and how the client will be described. You need to agree on industry descriptor, company size, geography, and which metrics are permissible. Without a brief, you risk publishing details the client assumed would be masked, or omitting context that makes the story credible.
Shift the brief to emphasize qualitative wins and process improvements. Document specific workflow changes, stakeholder feedback, or obstacles removed. Capture direct quotes that describe the before-and-after experience. Many B2B readers find operational narratives credible even without percentage lifts, especially if the challenge section is concrete and the solution is described in detail.
Only if the client explicitly approves publishing those names. Note competitor mentions in the brief, then ask whether the final case study can reference them or must use generic terms like previous vendor or incumbent platform. Some clients are comfortable naming competitors to differentiate their choice; others prefer to avoid giving any visibility to rivals.
Flag bilingual requirements, especially for Quebec distribution. Confirm whether metrics should appear in CAD or USD if revenue is mentioned. Note any interprovincial scope or regulatory context, such as CRA compliance or privacy rules that vary by province. If the client is a government entity or sells to public sector, document procurement-sensitivity around pricing and vendor evaluation criteria.
A functional brief ranges from one to three pages. It should be detailed enough to guide the interview and lock in approvals, but not so prescriptive that it stifles discovery. You will expand it after the interview with quotes, metrics, and asset details. Think of the pre-interview brief as the skeleton; the post-interview version becomes the full scaffold for drafting.