Meeting notes that show what changed, not just what was discussed

Meeting notes are most useful when the first section says what changed because of the meeting.

Many notes preserve discussion but hide the decision. A reader sees agenda items, comments, objections, and background links, yet still cannot tell whether the team approved the plan, delayed it, rejected it, or asked for another draft. That creates follow-up meetings whose only purpose is to reconstruct the previous meeting.

A stronger structure starts with a change summary. Write one to three bullets that say what is now different: a deadline moved, a feature scope changed, a budget owner was assigned, a support policy was narrowed, a launch condition was added, or a risk was accepted. Then list open questions separately. This prevents readers from treating unresolved ideas as confirmed decisions.

The second section should explain why the change happened. This does not need to be a transcript. A short reason is enough: customer support volume increased, legal review blocked one option, the team lacked staffing, the old metric was misleading, or a dependency moved. Reasons help future readers decide whether the decision still holds.

The final section should assign follow-up ownership. If nobody owns the next step, the note is only a memory aid. If someone owns the next step and the decision owner keeps the wording current, the note becomes part of the team’s operating system.

Meeting notes that show what changed, not just what was discussed

// COMMENTS

ON THIS PAGE