Decision log template: record what was agreed and why
Stefan Weiss
“Did we agree that, or only discuss it?” A decision log should let you answer without rereading weeks of meeting notes.
It records a choice, its status, who made it, why it was made and where to check the source. Use one entry per decision, with a stable ID so actions and later changes can point back to it.
Keep suggestions visibly separate from accepted decisions. When a choice changes, link the old entry to its replacement so the reason for the change survives.
The template below works in a spreadsheet or a shared document. It is intended for everyday project decisions; adapt it to your organisation's approval process.
A decision log template you can copy
Start with this record in a shared document. For a spreadsheet, use the labels as column headings and keep one decision per row.
Separate the date you wrote the entry from the date the decision was accepted. Otherwise a proposal entered on Monday can look as though it was approved on Monday.
For a decision with substantial context, use the spreadsheet as an index and link to a longer record. Microsoft's design-decision guidance uses architecture decision records to preserve context, the choice and its consequences, with a log providing a summary. The everyday project template here follows the same principle without requiring an architecture document for every decision.
Decide what belongs in the log
Record choices that people may need to understand or revisit: scope boundaries, delivery approaches, priorities, ownership arrangements or a significant change of direction.
A log does not need every preference voiced in a meeting. “Perhaps we should try a pilot” is a proposal. “We have agreed to run a pilot before the wider launch” records a choice.
Use a simple test: if someone asks about this in six weeks, would the choice and its reason help them continue the work? If so, it is probably worth recording.
Keep the log connected to the meeting summary, but give it its own purpose. The summary explains the discussion. The decision log lets someone find the accepted position without rereading that whole discussion.
A worked decision log example
This fictional example follows a team planning a small client workshop. The names, dates and choices are illustrative.
D-001: run a pilot before the wider programme
Status: accepted on 6 October. Decision-maker: project sponsor.
Decision: run one pilot workshop before scheduling the wider programme.
Reason: collect feedback on the format before committing to more sessions. Source: kickoff notes, item 4. Consequence: the wider schedule remains open until the pilot review.
D-002: use the existing client group
Status: accepted on 6 October. Decision-maker: project sponsor.
Decision: limit the pilot to the existing client group.
Reason: recruitment is outside the pilot’s agreed scope. Source: kickoff notes, item 5. Consequence: planning can use the current client list; recruitment work is excluded from this phase.
D-003: a possible date
Status: proposed; not yet accepted. Decision-maker: to confirm.
Proposal: run the pilot on 20 October.
Open dependency: facilitator availability has not been confirmed. Source: kickoff notes, open questions. No accepted date should appear in the schedule yet.
The third entry is not a settled date. Its presence helps people see what still needs a decision, provided the status is unmistakable.
Now imagine someone says, “I will check the facilitator's availability.” That is an action. Put it in the action tracker and link it to D-003. Checking availability does not approve the date, and an accepted date does not prove that the workshop has happened.
The action-item tracking guide covers that separate follow-up job.
Record the reason while the context is available
A decision without its reason can look arbitrary later.
“Use the existing client group” tells the reader what happened. Adding “Recruitment is outside the pilot's agreed scope” explains the constraint. That makes it easier to judge whether the choice still applies when the scope changes.
Write the reason that was actually given. If the discussion contains no clear rationale, say Reason not recorded and ask the decision-maker. Do not fill the gap with a plausible explanation.
Alternatives deserve the same treatment. Include options people considered, not options added afterwards to make the entry look thorough. A short honest record is more useful than a retrospective justification nobody agreed.
Check what the source actually supports
For each accepted decision, retain enough context for a reviewer to check it:
The meeting or document title and date.
The relevant section, passage or timestamp where available.
Who made or confirmed the choice.
Any qualification that limits what was agreed.
A transcript can help locate the discussion, but its wording and speaker labels can contain errors. For a consequential or ambiguous entry, check the original audio when it is available and appropriate, or ask the people involved to confirm the record.
Do not treat attendance as approval. A person being on the call is not evidence that they accepted every proposal. Silence is also a poor basis for assigning a decision to somebody.
The source may contain sensitive material that should not be shared with everyone who reads the log. Keep the log's summary useful on its own and manage access to supporting recordings separately.
Use Weeve to prepare a draft for review
Weeve’s transcript source view, using demo conversation data. Check the passage behind an answer before adding a decision to your log.
Weeve's decision-log workflow lets you ask about decisions across saved project conversations and review the sources. It prepares proposed text; it does not maintain your approval register or update a project tracker.
Try this prompt with a clearly defined set of recordings:
Draft a decision log from these project meetings. Separate accepted decisions, proposals and unresolved questions. For each entry, give the wording, date, supported decision-maker, stated reason and source. Include alternatives only where discussed. Mark missing information as unknown. Identify possible changes to earlier decisions without assuming the latest suggestion replaced them.
Read the sources before copying the result into your log. Check whether the answer covered the meetings you intended, whether a statement was qualified, and whether the named person had actually made the decision.
Chat with recordings can retrieve and compare saved material, but its answers can be incomplete or mistaken. A citation gives you something to inspect; it does not remove the need to inspect it.
For sensitive work, check the processing mode. Local Chat runs locally. Optional ChatGPT sends relevant text to that service.
When a decision changes, preserve both versions
Suppose the pilot later expands to include new clients. Keep D-002, change its status to Superseded, and add a new accepted entry explaining the revised scope and its reason. Link the two entries in both directions.
For example:
Do not overwrite the earlier wording as though the team always held the new position. The history explains why earlier work took the shape it did.
Before closing a meeting, read back the new decisions and ask the decision-makers to correct the wording. Then update the log while the context is fresh. Before the next meeting, filter for proposed decisions and the actions needed to resolve them.
Give one person responsibility for maintaining the log. They can tidy the wording and add links; disputed approvals and changed scope still go back to the person with authority to decide. A rejected proposal stays rejected unless a later decision explicitly revisits it.
Common questions
What is the difference between a decision log and an action log?
The decision log records choices and their reasons. The action log records work to do, who will do it and its progress. Link them where a decision creates work, while keeping approval and completion separate.
Who should own the decision log?
Assign one person to maintain it, usually someone already coordinating the project. That person can prepare entries, but the appropriate decision-maker should confirm disputed or consequential wording.
Should rejected proposals be included?
Include them when knowing why an option was rejected will prevent useful context from being lost. Label them clearly. You do not need a record of every passing idea.
Does a decision log prove that a decision was authorised?
The log records the evidence and approval information you put into it. Follow your organisation's approval process and retain the relevant confirmation; do not assume an AI-generated entry establishes authority.
