A decision log gives a team a durable record of important choices without forcing people to search through lengthy meeting notes. This guide explains what to record, provides a copyable decision log template, and shows how to review decisions monthly or quarterly so assumptions, outcomes, and ownership remain visible.
Overview
A decision log, also called a decision register or decision tracking template, is a focused record of choices that affect a project, system, process, or team. It is not a transcript and does not need to capture everything that happened in a meeting. Its purpose is to answer a small set of practical questions:
- What was decided?
- Why was it decided?
- Who owns the decision and its follow-up?
- What assumptions support the choice?
- How will the team know whether the decision worked?
- When should the decision be reviewed?
Use a decision log for choices that are expensive to reverse, affect multiple people, create dependencies, or are likely to be questioned later. Examples include selecting a deployment approach, changing an approval workflow, adopting a software integration, defining an incident process, or deciding which project scope to defer.
The log should be easy to search and separate from general meeting records. A meeting agenda template helps structure the conversation; the decision log preserves the resulting choice. A task list tracks work that follows, while the log explains the reasoning behind that work.
| Record | Primary purpose | Best question it answers |
|---|---|---|
| Decision log | Preserve important choices and their rationale | Why did we choose this approach? |
| Task list | Assign and monitor work | What needs to happen next, and who owns it? |
| Meeting minutes | Summarize discussion, updates, and actions | What did the meeting cover? |
What to track
A useful decision log contains enough context to support future readers without becoming another archive nobody maintains. Keep each entry concise, but do not remove the information needed to understand the choice.
Copyable decision log template
Decision ID:
Decision title:
Status: Proposed / Approved / Rejected / Reopened / Superseded
Date decided:
Decision owner:
Contributors or approvers:
Context and problem:
What required a decision? Include relevant constraints, deadline, or dependency.
Options considered:
1.
2.
3.
Decision:
State the chosen option in one or two clear sentences.
Reasoning:
Why was this option preferred over the alternatives?
Assumptions:
What must be true for this decision to work?
Expected outcome:
What should improve, change, or become possible?
Follow-up tasks:
- Task — owner — due date
- Task — owner — due date
Review date:
Evidence to check:
Review outcome:
Links or related records:How to complete each field
Decision ID and title: Use a consistent identifier and a descriptive title, such as “DEC-014: Adopt a shared incident handoff checklist.” Avoid titles such as “Process discussion,” which are difficult to find later.
Context and problem: State the situation that made action necessary. Include constraints such as a delivery date, system dependency, compliance requirement, or limited capacity when they materially influenced the choice.
Options considered: Record the realistic alternatives, not every idea mentioned in passing. Showing the alternatives prevents future readers from assuming that the chosen option was the only possibility.
Decision owner: Name the person accountable for maintaining the record and coordinating review. This does not necessarily mean that person made the decision alone.
Assumptions and expected outcome: These fields make a decision testable. For example, a team might assume that a new handoff checklist will reduce repeated clarification requests and expect fewer unresolved ownership questions during incidents.
Review date and evidence: Choose an observable signal to inspect. Depending on the decision, that may be completion time, defect patterns, support questions, adoption feedback, or whether a planned dependency was delivered. Avoid promising a precise measurement if the team does not have a reliable way to collect it.
Store access according to the sensitivity of the content. A decision log may contain internal project details, customer information, security considerations, or personnel context. Use the least permissive access that still allows the responsible team to work, avoid copying confidential details unnecessarily, and make ownership clear when a record is shared across groups.
Cadence and checkpoints
Decision logging works best when it is part of an existing workflow rather than an extra reporting exercise. Introduce the record at the point when a decision is made, then connect follow-up tasks to the team’s normal task management tools.
At the time of the decision
Draft the entry while the context is still available. Confirm the exact wording of the decision, identify the owner, list the next actions, and agree on a review date. If the discussion occurred in a meeting, link the relevant notes rather than copying the entire conversation into the log. For a practical meeting structure, see the guide to meeting cost and agenda planning.
During weekly planning
Check whether decision-related tasks are assigned and moving. A decision log should not replace a task list: copy actionable follow-up into the team’s task management system, then link the task back to the decision entry. Teams that already use a weekly planning workflow can add an agenda item for decisions awaiting implementation.
Monthly or quarterly
Review decisions with upcoming or overdue review dates. The appropriate interval depends on the decision’s risk and speed of change. A short-lived operational choice may need a quick check, while a broader process or architecture decision may deserve a monthly or quarterly review. At each checkpoint, confirm the status, inspect the selected evidence, record what happened, and decide whether to keep, revise, supersede, or reopen the decision.
Use a simple review queue with columns for due soon, overdue, awaiting evidence, and complete. This makes the log an active workflow instead of a static collection of historical notes.
How to interpret changes
A review is not automatically a reason to reverse a decision. It is an opportunity to compare the original assumptions with current conditions and decide whether the choice still fits.
- Keep: The expected outcome is appearing, the assumptions remain reasonable, and no significant new constraint has emerged.
- Adjust: The overall direction remains useful, but implementation details, owners, timing, or supporting tasks need to change.
- Reopen: A key assumption has changed, new evidence conflicts with the original reasoning, or the decision now creates an unacceptable trade-off.
- Supersede: A new decision replaces the old one. Link the new entry to the previous record so the history remains understandable.
- Close without action: The decision is no longer relevant because the project, constraint, or underlying problem has ended.
Look for patterns across the register. Repeatedly overdue reviews may indicate unclear ownership or unrealistic checkpoints. Many reopened decisions may point to weak assumptions, missing stakeholders, or decisions being made before enough information is available. A growing number of follow-up tasks may show that the team is recording decisions but not allocating implementation capacity.
Do not treat the log as a scorecard for individual judgment. Its value is to make reasoning visible, improve handoffs, and reduce repeated debate. When a decision changes, record what changed and why rather than silently editing the original entry.
When to revisit
Revisit this decision tracking template whenever the team makes a significant choice, and review the active register on a monthly or quarterly cadence. A more frequent checkpoint is appropriate when decisions involve fast-changing systems, urgent delivery work, customer impact, or substantial operational risk.
Update the template and its supporting workflow at least twice a year, or sooner when the team changes its documentation tool, access model, project structure, or review responsibilities. Check that links still work, archived decisions remain readable, statuses are used consistently, and sensitive records have appropriate access. If your team uses AI to convert voice notes into action items or summarize meetings, treat the generated output as a draft: verify the decision wording, owners, assumptions, and permissions before adding it to the register.
To put the system into practice today:
- Create one shared decision-log location with a clear owner.
- Copy the template and add a status, decision ID, and review date to every entry.
- Start with the next important team decision instead of trying to reconstruct every past choice.
- Link follow-up work to the team’s task management system.
- Add a recurring monthly or quarterly checkpoint to review due decisions.
- Record whether each decision should be kept, adjusted, reopened, superseded, or closed.
A lightweight decision log becomes valuable when it stays current. Keep entries focused, make ownership explicit, and use review dates to connect past reasoning with present conditions.
