How to write meeting minutes that actually produce action

Why most minutes fail

The failure is almost never effort. Someone typed diligently through the whole call. The failure is that the output is organised the way the conversation happened rather than the way the follow-up needs to happen.

Three specific problems recur:

• Decisions are buried inside narrative. "We discussed the pricing page at length and Rahul felt the hero was too busy, so we agreed to rebuild it" hides a decision inside a paragraph. Two weeks later nobody can find what was agreed without re-reading everything.
• Actions have no single owner. "The team will look at the analytics" is not an action item. It has no owner, so it has no one to chase, and it will not be done.
• The document is the destination. Minutes get emailed, read once, and closed. The action items live in a file nobody opens again, while the actual work happens somewhere else entirely.

The structure that works

Six sections, in this order. The ordering matters because it puts what people need first and the supporting detail last.

1. Header facts. Date, attendees, who was absent, meeting type, and the closure date by which the actions should be finished. That last field is the one most templates omit and the one that creates accountability.
2. Decisions. A short list, one line each. Not what was debated, what was settled.
3. Action items. The five-field format below. This is the section people scroll to.
4. Risks and open questions. Anything unresolved. Keeping it separate means it gets raised next time instead of quietly disappearing.
5. Discussion notes. Optional, and short. Context for anyone who missed the call.
6. Next meeting. Date, and what it needs to cover.

The five fields every action item needs

This is where minutes either work or do not. An action item without all five is a wish.

A template you can copy

Keep it in whatever tool you already use. The value is in the fields, not the formatting.

What changes for client meetings

Client minutes carry commercial weight, so two things tighten up.

Separate what you owe from what they owe. A single mixed list lets a client-side dependency sit unnoticed until it has blocked your team for a fortnight. Two lists make the dependency visible at a glance, and make it defensible later when a deadline slips because assets never arrived.

Write scope changes down as they happen. If something was agreed in a call that sits outside the retainer, it belongs in the minutes as a decision, in the language of scope. Reconstructing that conversation three months later, at invoicing time, is a considerably worse experience than writing one line at the time.

Where automation genuinely helps

Note-taking is a real cost: someone in every meeting is typing instead of thinking. The honest assessment of what software can and cannot take over:

• Handles well: transcription, pulling out explicit commitments, drafting the narrative sections, and suggesting an owner based on who normally does that kind of work on that account.
• Handles poorly on its own: implied commitments, deadlines that were never stated out loud, and anything depending on relationship context that was never spoken. It will confidently produce a plausible owner and date, and it will sometimes be wrong.

Which points at the working pattern: software drafts, a person confirms. The draft removes the typing; the review keeps the accuracy. What makes that review fast rather than tedious is showing the evidence beside each proposed action, so you are checking one line rather than re-reading a transcript.

Frequently asked questions