Workplace handoff path from meeting decision to reusable reply

A meeting decision note should let someone who missed the meeting understand the final choice, the reason, and the next owner without replaying the whole discussion.

The note starts with the decision question, not the meeting title. “Choose launch date for beta invite” is easier to reuse than “Growth sync notes.” Then record the final decision in one sentence, the owner who can answer follow-up questions, the people consulted, the options rejected, the reason for rejection, and the date or trigger for review. This is where a light DACI shape helps: driver, approver, contributors, and informed people do not need ceremony, but the roles prevent vague ownership.

The biggest mistake is writing a transcript when the team needs a receipt. A transcript preserves motion. A decision note preserves the point where motion stopped. The reader does not need every comment, but they do need to know why the team did not choose the second-best option. Rejected options are often the most valuable line because they stop the same debate from returning two weeks later.

A practical template has six lines: decision, owner, consulted, rejected options, risk, next check. For example, the team may choose to keep a manual approval step for one more release because support risk is higher than speed this week. The rejected option is automatic approval. The review trigger is a clean support week or a lower error rate. That record is short, but a new teammate can understand it.

The note should live where future work happens. If the team uses a shared doc, name the version. If it uses a channel canvas or project page, link the decision section from the task. If the decision only lives in chat, it will be hard to find when the context is needed most.

How to write a meeting decision note that survives the next handoff

// COMMENTS

ON THIS PAGE