Meeting Notes Format

The purpose of meeting notes is to let someone who wasn't there — or was there but is already on to the next thing — know what happened without rewatching the meeting. Optimize for that reader: structure over transcription, decisions over discussion, and clear ownership over vague summaries.

Header

• Open every set of notes with: meeting title, date, attendees (and notable absentees if their input mattered), and a one-line purpose ("Q3 roadmap review," "vendor contract decision"). A reader should know what this meeting was for before reading a single line of content.
• If the meeting is one of a recurring series, link to or reference the previous meeting's notes so open items carry forward instead of getting silently dropped.

Summary first

• Start the body with a 2–4 sentence summary of the meeting's outcome before any detail — what was decided, what's changing, what's next. Someone skimming should get the headline without reading the rest.
• Write the summary last, after drafting the rest of the notes, even though it appears first — you can't accurately summarize a meeting until you've laid out what actually happened in it.

Three buckets: decisions, actions, open questions

• Decisions: things the group actually agreed on and committed to. State each decision as a flat fact ("We will use Postgres, not MongoDB, for the new service"), not as a summary of the debate that led there. Include a one-line rationale only if it will matter later ("chosen for existing ops familiarity, not performance").
• Action items: every action item needs an explicit owner (one person, not "the team") and a deadline (a date, not "soon" or "next sprint" unless the sprint boundary is unambiguous to every reader). An action item with no owner is not an action item — it's a wish.
• Open questions: things raised but not resolved, explicitly listed as still-open rather than buried inside discussion prose. Each open question should have an owner responsible for bringing an answer to the next relevant meeting, even if the answer itself isn't in yet.
• Keep these three buckets visually and structurally separate — don't interleave a decision, then some discussion, then an action item in one paragraph. A reader scanning for "what do I need to do" should be able to jump straight to the actions section.

Verbatim quotes

• Quote someone directly only when their exact wording matters (a specific commitment, a customer's exact complaint, a legal or contractual phrase) — mark it clearly as a quote with attribution. Don't quote general discussion verbatim; paraphrase it into the relevant bucket instead.
• Never attribute a quote to someone without their exact words in front of you — a paraphrase presented as a quote can misrepresent what was actually said or promised.

What to leave out

• Don't transcribe the back-and-forth debate that led to a decision unless the reasoning itself is the deliverable (e.g. an architecture decision record). The decision and its one-line rationale are usually enough; the debate that produced it isn't worth preserving in most working notes.
• Don't include tangents, jokes, or side conversations that didn't affect the outcome, even if they were the most memorable part of the meeting live.

Deriving a follow-up email

• To turn notes into a follow-up email: keep the summary paragraph nearly verbatim, list action items with owner and deadline exactly as written in the notes, list open questions with their owners, and drop everything else. The follow-up email is a subset of the notes, not a rewrite — if you're inventing new phrasing at this stage, the notes weren't structured clearly enough in the first place.
• Send the follow-up within the same working day when possible; action items lose urgency fast once attendees are back in their own inboxes.