fac-sponsor-debrief
Drafts a one-page debrief for the call with the client or sponsor, covering what the session set out to do, what was produced, what feedback and barrier themes say in aggregate, the asks and the one d
SKILL.mdpacks/trainers-pack/skills/fac-sponsor-debrief/SKILL.md
GitHubSponsor Debrief
When To Use
The sponsor asks "so, how did it go?" and the only answer you have is "they seemed engaged". Use this before the debrief call to put one page in front of the person who asked for the session. It answers: what did the session do against what you asked for, and what is now yours to do?
When Not To Use
This is not the record for the room: run Session Summary and Decisions for that. It is not the team's private process note either: that is Facilitator Retro, and it stays with the team. If the debrief opens a next piece of work, that is a separate document: run Training Proposal.
Inputs
- The note from the kickoff call: what the session was for in the sponsor's words, and what each side committed to
- What was produced or practised (the session summary, or a few lines)
- The feedback summary in aggregate, any barrier themes people named (time, tool, process, workload), and what you would change in the design If you have none of this, I start from the original request and your own account of the day, and mark the output as a first draft.
Approach
Reviews of training transfer (Burke and Hutchins 2007; Grossman and Salas 2011) place much of what decides use after a session in the work environment, and Salas, Tannenbaum, Kraiger and Smith-Jentsch's 2012 review of the science of training treats what happens after the session as part of the work. The sponsor owns that environment, so the debrief is written to hand the right part back, as asks with dates. The failure it prevents: a warm call, "great feedback", and nothing changes around the people who came. It works in a plain chat, or as a page in Claude Docs (beta).
Workflow
- Ask three questions: what did the sponsor say at kickoff the session was for, what did each side commit to, and what one decision do you want from this call?
- Open with the kickoff note: the aim in the sponsor's own words, and the commitments on both sides with what happened to each. A commitment that was not kept is stated as a fact, yours included.
- State what was produced or practised as facts: the decisions taken, the tasks people practised, the material that exists. No adjectives about the mood of the room.
- Report what participants said in aggregate from the feedback summary: counts and themes, small groups suppressed, and the limit written beside it (a form cannot show use at work).
- List the barrier themes as conditions, and mark each as the sponsor's or the managers' to act on. This is usually the most useful part of the page, and the one a polite debrief leaves out.
- Write what you saw in the design: what worked and what you would change. Then turn the page into two or three asks with dates, and the one decision: run again, change, add follow-up, or stop.
- Prepare your sentence for the question "who engaged, who struggled, who has potential?": a plain no, and the aggregate offered in its place. You say it on the call; it is on the page so you are not caught improvising.
Output Format
# Sponsor Debrief
Session: [name] | Held: [date] | For: [sponsor name and role] | From: [trainer name] | Call: [date]
## What we set out to do
[The aim, in the sponsor's words from the kickoff call.]
- Commitment: [commitment], [sponsor / trainer / managers]: [done / partly / not done, as a fact]
## What was produced or practised
- [fact: decision taken, task practised, material that now exists]
## What participants said, in aggregate
Responses: [count] of [participants]. Groups under [minimum group size] are not reported. A form cannot show use at work.
| Question | What the counts show | Theme from comments |
|---|---|---|
| [question] | [counts per option] | [theme] |
## What could get in the way
- [condition people named] ([time / tool / process / workload]): [sponsor / managers] to act on
## What I saw in the design
- Worked: [design element and why]. Would change: [design element and how]
## What we need from you
1. [ask] by [date], owner [name] (two or three asks, no more)
## If asked about individuals
"[Your sentence: I do not report on individual participants. Here is what the group said as a whole.]"
## Decision
[Sponsor name] decides by [date] whether to run again, change, add follow-up or stop, and confirms who owns each ask.
Done When
- It fits on one page and opens with the sponsor's own words
- Every participant result is a count or a theme, with the suppression threshold applied
- Each barrier has someone outside the training room named to act on it
- The asks have dates and owners, there is exactly one decision, and no line could be traced to a single participant
Quality Bar
- Facts before impressions: "engaged" and "great energy" do not appear
- The limit of the evidence is stated once, and an uncomfortable finding comes with the ask that follows from it
- If a contract or policy governs what may be reported about participants, check with a qualified adviser
- The debrief reports on the session and the conditions around it; it refuses to report on named or identifiable participants.
Next
Run fac-training-proposal (Training Proposal) when the debrief opens a next piece of 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).