Meeting minutes: structure, what to write in each section, ready-made template

What minutes are actually for

Meeting minutes solve three problems, and none of them is “record that the meeting happened”. They lock in agreements, so that nobody argues a month later about what was settled. They assign ownership — every action acquires a name and a date. And they carry context to the people who weren't there, without a retelling in the corridor.

That gives you the test for quality: minutes are good exactly to the degree that someone absent from the meeting can act on them. If, after reading, that person still doesn't know what was decided and what to do now, the document isn't working — however many pages it runs to.

The seven sections

The order isn't arbitrary: it runs from what has to be understood fastest to what gets read selectively. Decisions sit above discussion because the reader needs the outcome, not the route to it.

1. Header. Topic, date, start and end time, who ran the meeting. Duration isn't a formality: it shows what the question cost, six months later when someone decides whether to convene again.
2. Attendees. Who came, and who was invited but didn't. The distinction matters: an absentee isn't automatically bound by a decision, but must be informed of it. An explicit absentee list is the list of people to send the minutes to personally.
3. Context. One or two sentences on why the meeting happened at all. Three months on, this is the only thing that will make the rest legible.
4. Decisions. The core section. What exactly was resolved — as a list, one item each, naming who made the call.
5. Tasks. The actions that follow from the decisions: wording, a single owner, a deadline.
6. Open questions. What was discussed but not settled. The section most often dropped — and wrongly: it is precisely what stops a question from vanishing before the next meeting.
7. Materials. Links to the documents, mockups and dashboards that came up.

Decisions: how to word them

The commonest failure here is recording the process instead of the result. “Discussed timelines”, “talked about budget” — that describes how the time passed, not what was reached. A decision should read as a statement you could check for truth.

The working formula: what was resolved + on what grounds + who decided. The grounds matter because decisions get revisited, and in a month the question won't be “what did we decide” but “why did we decide it that way”.

A note on “we agreed to revisit this”

That isn't a decision; it's the absence of one. If a question really is deferred, the deferral needs an owner and a date: “The pricing tiers are deferred until 15 September; Igor picks it up once the August numbers land”. A note like that belongs in open questions, not in decisions.

Tasks: what makes them doable

A task in the minutes differs from a task in the tracker in one respect: nobody will come and clarify it. So it has to stand on its own — the wording alone must make clear what counts as finished.

• An action verb up front. “Send”, “agree”, “collect” — not “the estimate” or “the access question”.
• A definition of done. Send it where, in what form, for whom to review. Without it the task closes on the assignee's sense that it's over.
• Exactly one owner. “The dev team” means nobody will do it: responsibility split between people belongs to none of them.
• A date, not “next week”. Relative deadlines expire the moment the minutes are read later than intended.

Three mistakes that void the minutes

1. A transcript instead of minutes. A verbatim record of the conversation is source material, not a document. Nobody will read it: the useful parts are interleaved with clarifications, jokes and returns to settled ground. A transcript is what minutes are extracted from — it cannot stand in for them.
2. Decisions without an owner. “Agreed to speed up hiring”, with no name, means nobody started. The test is simple: if for every item you can name the person to message tomorrow, the section is done.
3. Minutes two days later. Recall degrades fast, and the document's value with it: contested wordings can no longer be reconstructed, and participants begin remembering differently. The practical deadline is the same day, while the meeting is fresh at least for the author.

A template you can take

Markdown — pastes into any editor, tracker or knowledge base without edits.

# Minutes: [topic]

**Date:** [dd.mm.yyyy], [start]–[end]
**Chair:** [name]
**Attendees:** [names, comma-separated]
**Absent:** [names; “none” if everyone attended]

## Context
[1–2 sentences: why we met]

## Decisions
1. [What was resolved]. Grounds: [why]. Decided by: [name, role].
2. …

## Tasks
| What to do | Who | Due |
|---|---|---|
| [Verb + object + definition of done] | [one name] | [dd.mm] |

## Open questions
- [Question]. Revisit on [dd.mm], owner: [name].

## Materials
- [Title](link)

Minutes builder

Fill in the fields and the minutes assemble against the template above. Nothing is sent anywhere: it's all computed in your browser, and the page stores none of what you type.

Checklist before you send

Eight checks, each catching its own class of problem. Tick them off — the counter shows how ready you are.

What you don't have to do by hand

Decisions, tasks and open questions can be pulled out of the transcript: their wording is almost always spoken aloud. Whisperer keeps the transcript of the meeting and assembles structured notes with action items from it — leaving you to check the phrasing and fill in the missing dates. What stays manual is what should be: deciding what counts as a decision at all.

You still have to check. The model hears an agreement well, but it doesn't know which of the two Annas in the company owns billing. Names and dates are the one thing worth rereading every time.