Most meeting notes fail a simple test: does anyone open them again? Walk through any shared drive and you will find hundreds of documents titled "Meeting 2026-05-14" containing a half-transcript nobody has read since the hour it was written. The notes exist, the effort was real, and the value is zero — because the notes were optimized for capturing the meeting instead of serving the people who need something from it afterward.

The fix is not writing more. It is writing for the three questions people actually bring to old meeting notes: What did we decide? Who is doing what by when? Why did we decide it that way? Everything else — the winding discussion, the tangents, the verbatim quotes — is packaging. A useful meeting note answers those three questions in under thirty seconds of skimming. Here is a system for producing that note, from before the meeting starts to after it ends.

Before the meeting: build the skeleton

Good meeting notes are mostly written before the meeting begins. Five minutes of preparation does three jobs at once: it forces you to know why the meeting exists, it gives you a structure to capture into, and it means you start the meeting typing into a document instead of staring at a blank one.

The skeleton is short:

Title and date. Name the meeting after its purpose, not its attendees: "Decide Q4 pricing approach," not "Sync with sales."
Attendees. One line. This matters later — "who was in the room" is half of why anyone re-reads a decision.
Agenda as top-level bullets. Each agenda item becomes a heading-level bullet you will fill in live. If you cannot write three agenda bullets, that is a signal the meeting may not need to happen — a useful discovery to make before the hour is spent.
Two empty sections at the top: Decisions and Action items. Empty on purpose. Their emptiness at the end of a meeting is diagnostic: an hour that produced neither was a status update at best.

If the meeting is recurring, copy last week's action items into the skeleton. Reviewing them takes two minutes at the top of the meeting and does more for follow-through than any tracking tool, because it makes the room the accountability mechanism.

During the meeting: outline, don't transcribe

The single biggest upgrade to meeting notes is structural: take them as an outline, not as prose. Discussion is naturally hierarchical — topics contain arguments, arguments contain evidence and objections — and an outliner lets the notes mirror that shape as it happens. One bullet per point raised, details indented under the point they support. When the conversation jumps back to an earlier topic (it always does), you move the cursor back to that branch instead of appending "re: the earlier pricing point..." to the bottom of a page of prose.

Outlining also solves the transcription trap. Typing everything said feels diligent but produces the unread half-transcript, and worse, it costs you the meeting: a person typing verbatim is not thinking, and often not participating. Bullets force compression. You capture the point, not the sentence — five to ten words per bullet, speaker names only when the "who" carries weight ("Kana: legal review needs 3 weeks" matters; attributing every remark does not).

A few tactical habits that pay off:

Capture disagreement, not just conclusions. "Chose option B" is a fact; "Chose B over A because A requires the migration we're deferring" is a record. Six months later, the because is the part someone needs — it is the difference between re-litigating a decision and standing on it.
Flag things live instead of fixing them live. When something sounds like a decision or an action, mark it inline — a checkbox, a DECISION: prefix, whatever is fast — and keep up with the conversation. Sorting flags into their proper sections is an after-meeting job.
Park the tangents. Interesting-but-off-topic threads get one bullet in a "Parking lot" section. This respects the idea without derailing the agenda, and the parking lot often becomes the next meeting's agenda.
Write the unknowns down. "Nobody knew whether the contract auto-renews" is one of the most valuable bullets you can capture, because it converts a vague collective shrug into an assignable question.

Decisions and action items are a different kind of writing

Discussion notes can be loose; decisions and action items cannot. They are the part of the note that other people will act on, so they get held to a stricter standard.

A decision entry needs three parts: the decision, the reason, and the losing alternative. "Ship the beta to the waitlist only. Rationale: support capacity. Rejected: public launch (revisit after hire #2)." Two lines, and it will survive every future "wait, why did we...?" conversation.

An action item needs a formula: one owner, one verb, one date. "Mari to send the revised contract to Acme by Friday." Not "contract needs to go out" (no owner), not "Mari and Dev to look into contracts" (two owners is zero owners; "look into" is not a verb anyone can finish). If you cannot fill in all three parts, say so in the meeting — the thirty awkward seconds of asking "who owns this, and by when?" is the entire reason a note-taker earns their seat.

Write these as checkboxes, not prose, if your tool supports it. Checkboxes are scannable, they carry state, and in tools that aggregate tasks across notes, this week's meetings become a single actionable list instead of five documents to re-open.

After the meeting: the ten-minute close-out

Raw meeting notes decay fast — the shorthand that was obvious at 2 p.m. is cryptic by Thursday. Spend ten minutes, ideally within the hour, on a close-out pass:

Sort the flags. Move every marked decision and action into the sections at the top. The top of the note is now the summary; the outline below is the supporting record.
Repair the shorthand. Expand the bullets only you can currently decode. You are writing for a reader six weeks out who was not in the room — including future you.
Prune, don't polish. Delete the noise bullets; do not rewrite the survivors into paragraphs. The outline is the deliverable. Collapsed to its top level, it should read as the meeting's summary.
Link it into your notes. Connect the meeting note to the project and people it touches — with [[wiki-links]] if your tool has them — so the project note accumulates a dated history of every meeting that shaped it. If you run a daily note, a one-line pointer there keeps your chronological record intact too.

Sharing: send the top, keep the tree

What people need from you after the meeting is not the document — it is the decisions and the action items, delivered where they already look. Paste those two sections (rarely more than ten lines) into the team channel or a short email, with a pointer to the full note for anyone who wants the reasoning. This is also the accountability move: an action item posted publicly with a name and a date has a very different survival rate than one buried in a document.

The outline structure makes this nearly free. In Indenta, for instance, the meeting lives as a collapsible tree — decisions and checkboxed actions at the top, discussion nested below, action items aggregated into the built-in task view — and "Copy as document" turns the outline into clean prose-style Markdown for pasting anywhere. The User Guide covers the mechanics. But the system is tool-agnostic: skeleton before, outline during, three-part decisions and one-owner actions, ten-minute close-out, share the top.

Run it for two weeks of meetings. The test of success is pleasantly concrete: someone will ask "what did we decide about X?", and instead of a search through memory, the answer will be a link — to a note that answers in thirty seconds. That is a meeting note people actually use.

Try it in practice: Indenta is a free, offline-first outliner — nested notes, backlinks, tags, and peer-to-peer sync, with no account required. Start writing in your browser, or read the User Guide first.

← All articles