A complete workshop brief template with explanations for every section — so your briefs actually get read, get confirmed, and prevent the most common workshop failures.
A workshop brief is not a planning document for the facilitator. It's a shared alignment tool for everyone involved in making the session work.
The distinction matters. A planning document is read once by its author and filed. A brief is shared, reviewed, confirmed, and referenced throughout the process — from design through delivery through follow-up.
Most workshop briefs fail because they're written as planning documents. They capture the facilitator's understanding of the session without creating the mutual confirmation that makes a brief actually useful. The sponsor never reviews it. Gaps never surface. The misalignment that a good brief would have caught turns up during the session instead.
This template is designed to prevent that. Each section has a specific purpose, and the purpose of the brief as a whole is to surface misalignment before design work begins.
How to Use This Template
Fill in each section after your scoping conversation. Then share the completed brief with the sponsor with one explicit request: "Please review this and confirm that it accurately captures what we discussed. If anything is incorrect or missing, let me know before I start design work."
That sentence is not optional. The brief only works if the sponsor actively confirms it.
If the sponsor comes back with significant corrections, you need another scoping conversation. That's not a failure — it's the brief doing exactly what it's supposed to do.
The Workshop Brief Template
1. Business Context
What to include: A short (2–4 sentence) description of the organisational situation that is creating the need for this workshop. Why now? What's at stake?
Why it matters: This section ensures the facilitator and sponsor agree on the framing before anything else. It also gives participants essential context in any pre-read materials.
Example:
The product team has grown from 8 to 24 people over the past 18 months. Decision-making has slowed, priorities are frequently contested, and the team regularly misses sprint commitments due to unclear ownership. This workshop is intended to address the structural and cultural roots of these problems.
Red flag: If you can't write this section in clear prose, the scoping conversation isn't complete.
2. Workshop Purpose
What to include: One sentence stating what the workshop will produce or achieve.
Why it matters: This is the hardest section to write and the most valuable one to get right. A clear purpose statement is a design constraint, a success criterion, and a communication tool all in one.
Format: "This workshop will [produce / decide / align on / explore] [specific outcome]."
Example:
This workshop will produce a shared set of operating agreements for how the product team makes decisions, escalates conflicts, and manages cross-functional dependencies.
Red flag: If the sponsor can't confirm this sentence, you don't have a brief — you have a placeholder.
3. Desired Outcomes
What to include: Three to five specific outcomes written from the participants' perspective. What will they be able to do, decide, or agree on after this session?
Why it matters: Outcomes are the measure of whether the workshop succeeded. Vague outcomes produce unmeasurable results; specific outcomes create accountability for both the facilitator and the sponsor.
Format: "By the end of this session, participants will have [done / agreed / decided / produced] [specific thing]."
Examples:
- By the end of this session, participants will have agreed on a decision-making framework for the product team and named the situations in which it applies.
- By the end of this session, participants will have identified the top three sources of priority conflict and assigned an owner to each.
- By the end of this session, participants will have produced a draft RACI for the three most contested team processes.
Red flag: Outcomes that start with "participants will understand" or "participants will discuss" are not outcomes — they're activities. Push for what changes as a result.
4. Participant List and Roles
What to include: Name, title, and role in the session for each participant. "Role" means: decision-maker, subject-matter expert, implementer, or awareness attendee.
Why it matters: The participant mix is a design variable. Knowing who has decision authority, who brings relevant knowledge, and who will be implementing the outputs shapes every element of the session design.
Format:
| Name | Title | Role in Session |
|---|---|---|
| Jane Smith | CPO | Decision-maker |
| Marcus Lee | Engineering Lead | Subject-matter expert |
| Priya Nair | Product Manager | Implementer |
Also include: Total number of participants, and any notes about group dynamics relevant to facilitation (existing tensions, history, seniority differentials, etc.)
Red flag: If you can't identify at least one decision-maker in the participant list, the session may not be able to produce legitimate outcomes.
5. Constraints
What to include: A clear list of what's fixed, off-limits, or non-negotiable for the session.
Why it matters: Constraints define the design space. Discovering them mid-design wastes time. Discovering them mid-session can derail the entire day.
Common constraints to surface:
- Decisions that have already been made and are not up for discussion
- Topics that are politically sensitive or out of scope
- Time available (start time, end time, any fixed breaks)
- Budget for pre-work, materials, or follow-up
- Participants who cannot attend in person
- Reporting obligations (what gets documented and shared with whom)
Red flag: If the sponsor hesitates when asked about pre-made decisions, that hesitation is data. Probe further.
6. Success Criteria
What to include: How the sponsor will assess whether the workshop succeeded — both on the day and in the weeks after.
Why it matters: Success criteria make the purpose concrete and create a shared standard for evaluation. Without them, the sponsor and facilitator may have completely different views of whether the session worked.
Examples:
- On the day: All participants confirm they can articulate the new decision-making framework.
- Within two weeks: The framework has been documented and shared with the wider team.
- Within a month: The team can point to at least two decisions made using the new process.
Red flag: If success can only be assessed subjectively ("it felt good"), the outcomes probably need to be made more specific.
7. Post-Workshop Plan
What to include: What happens after the session — who owns the outputs, how decisions will be communicated, and when follow-up will occur.
Why it matters: A workshop without a clear post-session plan is an event. Events fade. The post-workshop plan is what connects the session to the change it's supposed to create.
Questions to answer in this section:
- Who will document the workshop outputs?
- Who owns communicating the outcomes to people not in the room?
- Are there follow-up actions that need to be assigned?
- When will the sponsor assess whether the outcomes are being implemented?
- Is there a follow-up session planned?
Red flag: If the sponsor says "we'll figure that out after," the workshop may not have sufficient organisational support to drive change.
8. Facilitator Role and Agreement
What to include: A brief statement of the facilitator's role, scope, and any specific agreements about independence, confidentiality, or decision authority.
Why it matters: This section protects both the facilitator and the sponsor by making implicit expectations explicit.
Items to confirm:
- Is the facilitator neutral or a contributing expert?
- What's the confidentiality agreement for content shared in the session?
- Who can override process decisions during the session (and under what circumstances)?
- How will the facilitator handle sensitive topics or conflict if they arise?
Confirming the Brief: The Step Most Facilitators Skip
Once the brief is written, share it actively — not as an attachment to a long email that might not be read, but with a specific, time-bound request.
"I've written up our scoping conversation in a brief. Please review section by section and let me know by [date] if anything is incorrect or if there are gaps. I'll begin design work once we've confirmed it."
If you don't hear back, follow up. A brief that isn't confirmed is a brief that hasn't done its job.
The brief is a living document, not a filed artefact. Update it when material information changes. Reference it during design to check that your choices serve the stated outcomes. Return to it if scope creep appears mid-project.
The brief is your contract with the reality of what you're being asked to facilitate. Keep it honest, keep it current, and keep it shared.
💡 Tip: Discover how AI-powered planning transforms workshop facilitation.
Learn MoreArticles connexes
Workshop Outcomes vs Outputs: How to Define What Your Session Actually Needs to Achieve
The difference between workshop outputs and outcomes — and a practical method for defining outcomes that are specific enough to design toward and meaningful enough to matter.
How to Scope a Workshop: The Conversation That Determines Whether Your Session Succeeds
A practical guide to scoping workshops from scratch — what questions to ask, how to find the real brief beneath the stated one, and when to push back before design begins.
Remote Facilitation Contracting: How Scoping and Briefing Change for Online Workshops
What changes about workshop contracting when the session is remote or hybrid — and the specific agreements, infrastructure checks, and design decisions that prevent remote workshops from collapsing.