Meeting notes are a running summary of a meeting, capturing discussion, context, and content. A decision log is a structured record of specific decisions made, the reasoning behind them, and the owner responsible for executing them.
The practical difference is what gets used afterward. Meeting notes get shared and filed; they are rarely read again. A decision log gets consulted every time someone asks 'did we not already decide this?'
Key takeaways
- Meeting notes capture the conversation; a decision log captures the conclusions.
- A decision log entry takes three lines: the decision, the rationale, and the owner.
- Most decisions are relitigated because they were never written down in a way anyone can find.
- Notes serve the participants; a decision log serves everyone who was not in the room.
Why it matters
The reason decisions get relitigated is not usually that people disagree. It is that nobody can find what was actually decided. A meeting summary says 'we discussed the launch date.' A decision log says 'we decided to launch on October 14th; Daniel owns the go-live checklist.'
Decision logs also surface accountability. When a decision is documented with an owner, the owner knows they own it. When it is buried in meeting notes, the owner can plausibly say they did not realize the task was theirs. One document structure eliminates an entire category of ownership ambiguity.
The three-line format matters. Decision logs fail when they become dense documents that require reading. The minimum viable decision log entry is: the decision in one sentence, the reason in one sentence, the owner and deadline in one line. If it takes more than that, the decision was not clear enough to be logged.
How it works in practice
How to run both without doubling the work
-
Separate capture from decision-logging
Take notes during the meeting. Write the decision log at the end, using the notes as raw material. The two are different outputs for different audiences. Notes go to attendees; the decision log goes to everyone affected by the decision.
-
Use the three-line format
Every decision log entry: one sentence for the decision, one sentence for the rationale, one line for the owner and target date. If you cannot write it in three lines, hold the decision until it is clear enough to document.
-
Log decisions as they are made, not afterward
The person running the meeting should call out decisions explicitly: 'That sounds like a decision. Who is writing it down?' The worst decision logs are written the next morning from memory. The best ones are written in the meeting room.
-
Put the decision log where the work happens
A decision log in a separate document nobody bookmarks is useless. Put it in the project channel, the Notion page, or the Linear ticket. It needs to be findable by someone who was not in the meeting.
-
Review open decisions at the next meeting
Open the next relevant meeting by reading the last three decisions from the log. Who owns them? Where do they stand? This takes ninety seconds and prevents the meeting from relitigating what was already settled.
Common mistakes
Sending meeting notes as a substitute for a decision log
A four-paragraph summary is not a decision log. The person who needs to act cannot find their action item. The person who missed the meeting cannot determine what changed. Write a separate, searchable decision list at the end of every summary.
Logging discussion as if it were a decision
A decision log entry that reads 'we talked about the timeline' is not a decision log; it is a note. A decision log entry reads 'we will ship on October 14th.' The test is whether it contains a clear commitment and an owner.
Skipping the rationale
A decision without its rationale will be questioned again when the context is lost. Logging 'Daniel owns the launch checklist' is half a record. 'Daniel owns the launch checklist because he has the most context on dependencies' is the full one.
Making the decision log a long document
Once a decision log grows past two pages, it stops being consulted. Archive completed decisions after 90 days. Keep the active log short enough to scan in under a minute.
What it sounds like
Product and engineering sync after a messy Q2 launch.
“We decided this in April,” Merav said. “It is in the notes from the April 3rd meeting.”
Daniel opened the notes. “It says ‘we discussed the ownership model.’ That is not a decision. That is a summary of a meeting.”
Guy set a rule: every meeting would end with a decision log read-out. If a conclusion could not be stated in one sentence, they had not decided yet.
Questions managers actually ask
What is the minimum a decision log needs to include?
Three things: the decision itself in one sentence, the reason in one sentence, and the owner with a target date. Everything else is optional. If you add more, you are building a meeting summary, not a decision log.
Where should the decision log live?
Wherever the work is tracked. For engineering teams, a pinned Notion page or a Linear project description. For cross-functional teams, a shared Slack channel pinned post. It needs to be findable without asking the person who wrote it.
Who should own the decision log?
The meeting organizer owns the initial write. The decision owner owns it from the moment they are named. Responsibility transfers at the point of logging.
How long should we keep old decisions?
Archive decisions once the outcome is shipped or irrelevant. A working decision log should fit on one screen. Decisions older than 90 days that have no owner or are already done should be moved to an archive.
What about decisions made over Slack or email?
Log them too. The channel does not matter; the record does. When a decision is reached over Slack, write a three-line summary and drop it in the decision log. The conversation thread is not a substitute.
What do you do when someone relitigates a logged decision?
Share the log entry. If the person wants to reopen the decision, that is a new meeting topic with new information, not a continuation of the original discussion. The log entry is the record; redirect to it.
See how Leap improves execution in your meetings
Leap sits in your meetings, captures decisions and owners in real time, and shows you where execution breaks down before the week is out.