What to write in a meeting decision note before everyone forgets

A meeting decision note should preserve the chosen option, rejected alternative, owner, deadline, and review trigger before the conversation fades from memory.

Teams often leave a meeting with agreement but no durable record. A week later, someone asks why the team picked one tool, changed one policy, delayed one launch, or accepted one workaround. The calendar invite has no answer, the chat thread is half jokes and half links, and the task ticket only shows the final assignment. A decision note prevents that drift.

Start with the question being decided. “Which support replies should move into the public FAQ?” is better than “FAQ discussion.” Then record the chosen path in one sentence, followed by the reason it won over the main alternative. If the team chose a manual review step because automation created false positives, name that tradeoff. If the team picked the cheaper tool because migration time mattered more than feature depth, say so.

The note should include owner and next check. A decision without an owner becomes background noise. A decision without a review trigger becomes permanent by accident. Good review triggers are dates, usage numbers, customer complaints, legal changes, incident counts, or handoff failures. The trigger should tell future readers when the decision deserves another look.

Finally, keep the note separate from raw minutes. Raw notes can be messy. The decision note should be the reusable answer: what changed, why, who acts next, and what evidence would reopen it.

What to write in a meeting decision note before everyone forgets

// COMMENTS

ON THIS PAGE