Session Flo logoSession Flo
14 min readInteractivity

Session Recaps: Giving People Something to Take Away

A recap is not minutes. It is the two-minute read that turns ninety minutes of discussion into decisions people can act on. Here is what goes in one, when to send it, and how to assemble most of it while the session is still running.

By Session Flo

Key takeaways

  • A recap has three audiences - the people who were there, the people who were not, and the version of the team that reopens this decision in six weeks.
  • Write it as decisions, owners and dates first; the narrative of what was discussed goes underneath, or not at all.
  • Assemble it during the session from poll results, word clouds and typed contributions rather than reconstructing it from memory two days later.
  • Send within four hours for a working session and by the next morning at the absolute latest - a recap that arrives on Thursday for a Monday workshop is an archive, not a prompt.
  • Quote the room back to itself verbatim; people read a recap that contains their own words far more carefully than one that summarises them.
  • Track whether the actions in the recap get referenced anywhere afterwards - if nothing cites it, the problem is the session, not the document.

A session recap is the short document that goes out after a workshop, all-hands or training session and states what was decided, who owns what, and what people actually said. It is not minutes, it is not a transcript, and it is not a list of topics covered. Done properly it takes a reader about two minutes and leaves them able to act without asking anyone a follow-up question.

Most recaps fail for the same reason: they get written from memory, late, by an exhausted facilitator. By then the specific things have evaporated - the exact wording of the third option, who volunteered for the data pull, the two objections that nearly flipped the decision. What survives is a summary of themes, which nobody reads, because a list of themes tells people nothing they did not already know by leaving the room.

This guide covers the five parts a recap needs, how to build most of it while the session is still running, when to send it, how the format changes between a twelve-person workshop and a four-hundred-person town hall, and how to tell whether anyone is reading the thing at all.

What a recap is for, and what it is not

A recap serves three audiences at once, and they want different things. The people who were in the room want an anchor - one place that confirms what was agreed so they do not have to trust their own memory of a fast-moving hour. The people who were not there want the decision and the reasoning, compressed, without wading through discussion they cannot contribute to. And the third audience is your team in six weeks, when someone reopens the question and needs to know what was already considered and rejected.

That third audience is the one worth designing for, because it is the one that determines whether the session had any durable effect. A decision with no written record gets remade, usually badly, by whoever is loudest in the room where it comes up again. Writing down the rejected options and why they were rejected is the cheapest insurance a facilitator can buy, and it takes about ninety seconds.

What a recap is not: it is not a chronological account of the meeting. Nobody needs to know that you started with a check-in, moved to a brainstorm and broke at eleven. Chronology is how facilitators experience a session and it is the least useful ordering for a reader. Lead with the output; the process only matters where it explains why a decision holds.

The five parts of a recap that gets read

Every useful recap contains the same five blocks in roughly the same order. The order matters more than the styling: readers skim from the top and stop when they have found what applies to them, so the thing you most want acted on has to be near the top.

Decisions, stated as decisions

Three to six lines, each one a full sentence with a subject and a verb. 'We are shipping the shorter onboarding flow to new accounts from 3 March' - not 'discussed onboarding flow options'.

Owners and dates

A named person and a real date for every action. No 'the team', no 'ASAP', no 'TBC'. An action without a name attached is a wish, and everyone reading knows it.

What the room said, verbatim

The poll split, the word cloud's top five words, three or four typed comments quoted exactly. This is the block people scroll down to find, because it contains their own words.

What was rejected and why

Two or three lines. The options considered and the reason they lost. This is what stops the same argument being had again in six weeks by people who were not in the room.

The open questions

What you did not resolve, named honestly, with who is picking it up and when it comes back. A recap that pretends everything was settled loses credibility with everyone who was there.

Why the verbatim block does the heaviest lifting

If you cut four of the five blocks, keep the quotes. People read a document containing their own sentences with an attention they never give a summary. Someone who typed 'the handover step is where everything falls over' at minute forty will read the entire recap to see whether their line made it, and in reading it they absorb the decisions above it.

It also solves a trust problem quietly. A group that watches its raw contributions reappear in the follow-up learns that typing something has consequences, which raises participation in the next session more reliably than any amount of encouragement. A group whose contributions vanish into a facilitator's summary learns the opposite, and learns it fast.

Build the recap while the session is running

The single biggest improvement you can make to recaps is to stop treating them as post-session work. Almost everything in a good recap exists during the session; the job afterwards should be arranging it, not remembering it.

This changes how you facilitate, slightly and for the better. Knowing you have to write down a decision as a sentence forces you to get decisions stated as sentences in the room, which is exactly the discipline most working sessions are missing.

1

Decide the recap's shape before the session starts

Write the five headings into an empty document while you are building the agenda. If you cannot guess what will go under 'Decisions', your agenda is not designed to produce any, and that is worth knowing an hour before rather than an hour after.

2

Capture decisions in the room, out loud

When a decision lands, say it back as a sentence and ask whether that is right. 'So: shorter flow, new accounts only, from March. Yes?' Then paste that exact sentence into the document. Confirmed in the room, it needs no editing later.

3

Screenshot or export every activity result

Poll splits, word clouds, ranking outcomes and open-text responses are the raw material of the verbatim block. Session Flo keeps every activity result attached to the session so the recap can be assembled from the real data rather than your recollection of the bar chart.

4

Name owners while the person is in the room

Never leave a session with an unowned action. Ask 'who is doing this by when' in front of everyone, and type the name and date immediately. Assigning owners by email afterwards has roughly a fifty per cent success rate and generates three days of ambiguity.

5

Write the rejected-options lines during the break

The reasoning for a rejection is the first thing to fade. Two lines during the coffee break, while the argument is still fresh, beats twenty minutes of reconstruction the next morning.

6

Spend the last five minutes reading it back

Put the draft on screen before people leave and read the decisions and owners aloud. Corrections cost seconds in the room and cost an email thread afterwards. This also means nobody can claim later that they did not agree to it.

7

Send it before you do anything else

Tidy the formatting for five minutes and send. A rough recap in the inbox by three o'clock beats a beautifully formatted one on Thursday by a distance that is hard to overstate.

When to send it

Speed matters more than polish, and it matters for a specific reason: the value of a recap decays with the memory of the session. People remember a workshop in detail for a few hours, in outline for a day or two, and as a general impression thereafter. A recap arriving inside the detail window gets read and corrected; one arriving in the impression window gets filed.

There is a second effect worth exploiting. Unfinished work stays mentally active in a way that finished work does not, so a recap that names an open question and a date is far more likely to be picked up than one that presents everything as closed. Do not tidy away the loose ends to make the document look neat - the loose ends are the part that generates action.

Last 5 minutes of the session

Decisions and owners read aloud from the draft and corrected in the room. Nothing goes into the recap that the group has not heard.

Within 30 minutes

Paste in the activity results - poll splits, word cloud, top-ranked items. This is copying, not writing, and it is the block that takes longest if you leave it.

Within 4 hours

Send. For a working session this is the target: still the same day, still inside the detail window, still early enough for someone to start their action today.

Next morning at the latest

The hard deadline for anything - a full-day workshop, a large event. Past 24 hours you are writing an archive document, which is a different and much less useful thing.

One week on

A three-line nudge against the same action list. Not a new document: the original recap, with a status against each owner. This is where the follow-through actually happens.

Match the format to the session

A twelve-person decision workshop and a four-hundred-person town hall need genuinely different documents, and the common mistake is to send the workshop format to the large audience. At scale, most readers have no action and no decision rights, so a list of owners means nothing to them; what they want is the answer to 'what changed and does it affect me'.

Session typeRecap lengthLeads withSend windowMost common mistake
Decision workshop (8-20)150-300 wordsDecisions and ownersSame dayBurying the decision under a narrative of the discussion
Team retrospective (5-12)100-200 wordsThe experiments being triedSame dayListing every observation instead of the two changes agreed
Training session (10-60)200-400 wordsThe three things to rememberSame day, plus a nudge at day 7One long summary instead of spaced reminders
All-hands or town hall (100+)200-350 wordsWhat changed and what it means for youWithin 24 hoursReposting the slide deck and calling it a recap
Multi-day offsite400-600 wordsThe commitments, day by dayNext morningWaiting until everything is 'properly written up'
Recurring weekly meetingUnder 100 wordsChanges since last week onlyWithin the hourRepeating standing items nobody needs restated

Write it so it is skimmed, not read

Top Tips

  • Put the decisions above the fold. Assume half your readers see only the first screen of the email or message, and design that screen to be sufficient on its own.
  • Use one line per decision and never a paragraph. Paragraphs invite skimming past; single lines with a name and a date at the end get scanned and remembered.
  • Bold the owner names, not the headings. Readers scan for their own name first - make that scan take half a second rather than making them read the whole list.
  • Quote the room exactly, including the awkward phrasing. Cleaning up someone's typed comment removes the thing that made it credible, and the person who wrote it will notice.
  • Give numbers as splits, not percentages of one option. '14 of 22 chose the shorter flow' carries the size of the room with it; '64 per cent' hides whether that was seven people or seven hundred.
  • Say what you want the reader to do, in the first two lines, if there is anything at all. A recap that requires the reader to infer their own obligation will not produce one.
  • Keep it in the body of the message. An attachment or a link to a document adds a click, and a click is where about a third of your readers stop.

What a weak recap looks like beside a strong one

The difference is almost never effort. Weak recaps are often longer than strong ones - the writing time went into narrating the session rather than extracting the output from it.

The recap nobody reads

  • Subject line: 'Notes from Tuesday'
  • Opens with 'thanks everyone for a great session'
  • Chronological account of each agenda item
  • Actions written as 'the team to look into pricing'
  • Sent Thursday, two days after the workshop
  • Attached as a PDF nobody opens on a phone
  • No mention of anything that was left unresolved

The recap that produces action

  • Subject line: 'Onboarding: 3 decisions, 4 owners, dates inside'
  • Opens with the decision that affects the most people
  • Five bold names with a date each, on five lines
  • Poll split and four typed comments quoted verbatim
  • Sent at 15:40 the same afternoon
  • In the body of the message, readable on a phone
  • Two open questions named, with who is picking them up

Recaps for hybrid, remote and asynchronous audiences

In a hybrid session the recap is not a courtesy for the people who missed it - it is the primary artefact for anyone who was not in the physical room. Remote attendees typically catch less of the side conversation, the whiteboard scribble and the nods that pass for agreement in the room, so more of the actual decision has to be reconstructed from the document than the facilitator realises.

That has a practical consequence: capture decisions in a channel everyone can see during the session, not on a flip chart. If the decision is typed into the shared screen as it is made, remote participants can correct it in real time, which is the whole point. A flip chart photographed at the end has already lost the people who could not read it.

For genuinely distributed teams across time zones, treat the recap as the session for the people who could not attend. That means writing enough context that a colleague eight hours ahead can disagree with the decision the next morning without having to schedule a call. Two extra sentences of reasoning in the recap is cheaper than the meeting you would otherwise need to hold.

Where the group is large, publish rather than email. A single stable location that gets updated - with the poll results, the quotes and the action status - beats a chain of forwarded messages where three versions of the action list circulate at once.

How to tell whether the recap is working

There is one honest test: does anything cite it? If, a week later, someone in another meeting says 'per the recap, we agreed X', the document is doing its job. If nobody ever refers to it, the document is decorative, and the interesting question is why.

Usually the answer is not that the recap was badly written. It is that the session did not produce anything worth recording. A workshop that generates no decisions produces a recap of topics discussed no matter how skilled the writer, and no amount of formatting will make that document useful. If your recaps keep coming out thin, look at the session design before you look at the writing.

The other signal worth watching is corrections. A recap that never gets corrected is probably not being read carefully. When someone replies to say the second decision is stated too strongly, that is not a failure - it is the document doing exactly what it should, forcing an ambiguity into the open where it can be settled in two messages rather than in a meeting three weeks later.

"
If nobody ever cites the recap, the problem is rarely the writing. It is that the session did not decide anything worth citing.

Make the recap a standing part of the design

Facilitators tend to treat the recap as admin that happens after the real work. It is more useful to treat it as the last activity in the agenda, with time booked for it, because that is what forces the session to produce something recordable in the first place.

Book the final five minutes for reading the draft back. Put the recap template in the same place as the agenda template. And tell people at the start of the session that everything they type goes into a summary that lands in their inbox the same day - it changes how carefully they type, and it makes the follow-up feel like part of the session rather than a chore appended to it.

Do that consistently for a couple of months and something shifts in how the team treats sessions generally. Meetings that reliably produce a short, honest, same-day record start being used for decisions, because people learn that decisions taken there actually hold. Meetings without one keep getting relitigated, and eventually stop being worth attending.

Frequently asked questions

How long should a session recap be?

Between 100 and 400 words for almost every session, and under 600 even for a multi-day offsite. The constraint is that it has to be readable in about two minutes on a phone. If you find yourself over that, the extra length is almost always narrative about the discussion rather than output from it - cut the narrative first, then the rejected-options block, and never the decisions or the verbatim quotes.

Should the recap include everything people typed during the session?

No - include the aggregate and a handful of exact quotes, and link to the full set if people want it. A word cloud's top five words plus four representative comments gives the shape of the room without producing a wall of text nobody reads. The exception is a feedback or retrospective session, where seeing the full unedited set is part of the trust contract, in which case publish everything and say so up front.

Who should write the recap - the facilitator or a notetaker?

The facilitator should own the decisions and owners, because those need to be confirmed in the room as they are made, and only the person running the session can do that. A separate notetaker is useful for capturing quotes and detail during discussion, which frees the facilitator to actually facilitate. What does not work is delegating the whole thing to someone who was not steering the session - they will produce a chronological account, because that is all they have.

What do I do if a decision was not actually reached?

Write that down plainly: what the options were, where the disagreement sits, who is deciding, and by when. A recap that manufactures a decision to look tidy is worse than one that names an impasse, because the fake decision will be discovered later and it will cost you credibility. Naming an unresolved question with an owner and a date is a legitimate and often valuable outcome for a session.

How do I get people to read the recap at all?

Put the decision in the subject line, keep it in the message body rather than an attachment, bold the owner names, and send it the same day. Beyond that, the strongest lever is including people's own words - readers who suspect they might be quoted read a great deal more carefully. If you have done all of that and it is still ignored, the sessions themselves probably are not producing anything anyone needs.

Do recurring meetings need a recap every time?

They need a very short one - under a hundred words, covering only what changed since last week. Repeating standing items trains people to skip the message entirely, and once they skip it twice they will skip the week it actually matters. For a weekly meeting the useful format is a running list where the same document is updated and the message says only what moved.

Keep reading

Related articles

Ready to run better sessions?

Create interactive events with live polls, quizzes, icebreakers, and more.