How to write a meeting summary people actually read
Lead with decisions and owners, keep discussion to a few lines, and send it the same day. A structure that works whether a person or an AI tool writes the first draft.
On this page
Key takeaways
- Lead with decisions and action items; context goes last.
- Every action item needs an owner and a date.
- A shared agenda makes the summary easy to write.
- Review AI-drafted summaries for names, numbers and sensitive content before sending.
Put decisions first
Most people open a summary to find out what was decided and what they have to do. Put that at the top. Discussion and context go below, briefly, for people who need the reasoning.
| Section | What to write | Length |
|---|---|---|
| Decisions | Each decision in one sentence | As many as were made |
| Action items | Action, owner, due date | One line each |
| Open questions | What still needs an answer, and from whom | One line each |
| Context | Why the decisions were made | A short paragraph |
Write it from the agenda
GitLab’s handbook on meetings recommends a written agenda shared in advance and notes taken in the same document. If the agenda exists, the summary is mostly a matter of filling in outcomes under each item.
If an AI tool drafts it
Treat the draft as a first pass. Check names, numbers and owners against what was said, and delete anything that should not be shared with everyone on the distribution list.
Frequently asked questions
When should the summary go out?
The same day, while details are fresh and before action items go stale.
Who should receive it?
Attendees plus anyone who owns an action item. Avoid sending full transcripts to wide lists.
