“Why did we change the weekly meeting?” is easy to answer on the day. A month later, people may remember the new format but forget that it was only a trial.
A decision log records a choice, its reason, its scope, and whether it still applies. Link each entry to the meeting notes that support it. If no choice was made, label the entry as proposed or deferred rather than writing it as an agreement.
A decision is not an action item
“Try a shorter weekly call” describes a choice. “Morgan will send the new agenda on Thursday” describes work needed to carry it out. Keep the records linked, but track the task separately in your meeting action list.
Write a decision entry when someone is likely to ask why an option was chosen: a change in project scope, an agreed working method, or a trade-off the team accepted. You do not need a formal entry for every small preference.
Example: a trial that could be mistaken for a permanent rule
The following project meeting is fictional. A team considers three options for its weekly update: keep the 45-minute call, replace it with writing, or send a written update followed by a 15-minute question session. It agrees to try the third option for four weeks.
A rushed note says, “We're stopping weekly meetings because written updates are better.” That sentence drops the question session, erases the trial period, and claims a benefit nobody has measured.
A useful entry would look like this:
D-014: Weekly project updates
Status: Agreed for a four-update trial.Choice: Send a written update before a 15-minute question session. Applies to this project team only.
Reason: Move routine progress reports out of the call while retaining time for questions. The trade-off is preparing the written update beforehand.
Alternatives: Keep the existing call; use written updates without a call.
Review: Reconsider after the fourth update. Morgan maintains the record; the agenda-preparation task is tracked separately.
In a real entry, add the meeting date and a link to the agreement, including who confirmed it. The fictional passage above cannot stand in for that evidence.
A decision log template you can copy
Use one entry per choice. These six prompts fit in a shared document:
- Question and ID: What did the team need to decide?
- Choice, status, and date: What was agreed, for whom, and for how long? Or is it still proposed?
- Reason and alternatives: Why this option? What disadvantage did the team accept?
- Source and confirmation: Where is the relevant passage, and who confirmed the choice?
- Record owner and related tasks: Who keeps the entry current? Where is the follow-up work tracked?
- Review and history: What would prompt a review? Has another decision replaced this one?
Software teams use architectural decision records for a related purpose. AWS describes an ADR as a record of a technical choice, its context, and its consequences. The everyday meeting template here borrows that principle; it is not a software-architecture requirement.
Check the words that change the decision
Read the source before marking an entry “agreed.” Watch for limits such as “for this team,” “after approval,” and “for four weeks.” They belong in the decision sentence, not in a distant footnote.
Keep the reason stated in the meeting separate from your own explanation. If nobody recorded a reason, write “reason not recorded” and ask. Date any later clarification so a reader can tell when it was added.
The person maintaining the log is not automatically authorized to make or change the decision. Record the team's actual confirmation process rather than assuming that editing the document settles the question.
When a decision changes, keep the earlier entry
Correcting a typo and choosing a different option are different events. For a replacement decision, create a new entry, mark the old one “superseded,” and link them in both directions. AWS's ADR process also preserves accepted records when a later decision replaces them.
This lets a new teammate see both the current rule and why it changed. For a meaningful factual correction, add a short correction note instead of silently changing the account of the meeting.
Store the log beside the team's meeting records. Our meeting knowledge-base guide covers how to make those linked records easier to find.
Start with one recent decision someone might question. A reader should be able to find the choice, reason, limit, and source without reconstructing the whole discussion.
Edited by Recolx Editorial. Updated September 17, 2026.
