A decision log is a running list of the decisions a team or project has made: what was decided, when, by whom, why, and what it affects. It's one table, kept in one place, that anyone can check before they reopen a question or start work that depends on it.
Teams keep decision logs because decisions get lost. They get made in a call, a chat thread or a hallway, and three weeks later nobody remembers the reasons, so the same topic comes back to the next meeting. This guide gives you a decision log template you can copy, the columns worth including, how a decision log differs from meeting minutes and a RAID log, and the habits that keep it up to date.
What is a decision log?
A decision log records outcomes, not discussions. Each entry is one decision, written as a sentence someone outside the meeting would understand: "Launch in two markets first, not five" rather than "Discussed launch scope." Alongside the decision it records the context that led to it and the person who made the call.
In project management, a project decision log is part of the project record. It shows how the scope, timeline and approach got to where they are, which helps when a stakeholder asks why something changed, when a new person joins, or when you review the project at the end.
What to record in a decision log
Keep it short enough that people fill it in. These columns cover what you'll need later:
| Column | What goes in it |
|---|---|
| Date | When the decision was made. |
| Decision | One clear sentence, written so it makes sense on its own. |
| Context and options considered | The problem, the options on the table and why this one won. Two or three lines is enough. |
| Owner | The person who made the call and answers for it. |
| Consulted | Who gave input, so you know who to involve if it's revisited. |
| Status | Proposed, decided, superseded or reversed. |
| Review date | When to check the decision still holds, if it should be checked at all. |
| Link | Where the detail lives: the meeting, document or ticket. |
If you track many decisions, add an ID column so people can refer to "decision 14," and an "affects" column for the teams or workstreams the decision touches.
Decision log template you can copy
Paste this into a spreadsheet, a shared document or your project tool. The three rows show the level of detail that works.
| Date | Decision | Context and options | Owner | Consulted | Status | Review |
|---|---|---|---|---|---|---|
| Mar 4 | Launch in two markets first, not five. | Support can't cover five time zones yet. Options: five markets, two markets, a waitlist. Two keeps the date. | Head of product | Sales, support | Decided | After the first 30 days |
| Mar 11 | Ship sign-in without social login. | Social login adds two weeks of security review. Usage data shows most customers sign in with email. | Engineering lead | Security, design | Decided | Next quarter |
| Mar 18 | Move weekly status to an async update. | The meeting was mostly updates. Blockers will go to a short call with only the people involved. | Project manager | Whole team | Decided | In one month |
If your team works in Excel or Google Sheets, freeze the header row, turn on filters for owner and status, and keep the newest decisions at the top. A decision log template in Excel works fine for a single project. It gets harder once decisions come out of many meetings and nobody remembers to copy them over, which is where the habits below matter.
Use the decision log template in Nova
The decision log template in the process library gives your team a ready-made session for recording decisions. For decisions that still need to be made, the decision meeting template keeps the conversation on options, trade-offs and a final call.
Decision log vs meeting minutes vs RAID log
These three records overlap, and teams often keep one when they need another.
| Record | What it holds | When you read it |
|---|---|---|
| Meeting minutes | What was discussed in one meeting, in order, with action items. | Rarely, usually to check who said what. |
| Decision log | Only the decisions, across all meetings and channels, with the reasons. | Before reopening a topic, starting dependent work or onboarding someone. |
| RAID log | Risks, assumptions, issues and dependencies. Some versions use D for decisions. | In project reviews, to manage what could go wrong. |
The decision log is the one people actually go back to, because it's short and it answers the question they have: "Did we already decide this?" If you keep a RAID log, link each decision that resolves an issue or a risk to its entry there.
How to keep a decision log up to date
Most decision logs die in the second month. The template is rarely the problem. The habits are.
- Log at the moment of decision. End every meeting that decides something by reading the decision out loud and adding it before people leave. Logging "later" means never.
- Turn meeting conclusions into entries. If every meeting ends with a written conclusion, the decision log is just the list of those conclusions. Make the conclusion part of the meeting, not an extra task.
- Capture decisions made outside meetings. When a call gets made in chat or email, the person who made it adds the entry. Agree on that rule with the team.
- Name one owner for the log. One person checks weekly that recent decisions are in and written clearly. Usually the project manager or chief of staff.
- Don't delete, supersede. When a decision changes, add a new entry and mark the old one as superseded. The history is the point.
- Point people to it. When someone reopens a settled question, link the entry. After a few times, people check the log first.
Decision log examples
A project decision log
On a website redesign, the log might record: the choice of design direction after client review, the decision to cut the blog migration from phase one, a launch date moved by one week because of late content, and the agreement to keep the old URLs with redirects. Each one would otherwise come back as a question from the client or a new team member.
A leadership team decision log
For a leadership team, the log holds the decisions that set direction: hiring freezes and exceptions, pricing changes, which projects get funded this quarter, and policy changes. Review dates matter more here. A decision like "pause hiring in sales until Q3" needs a date when someone checks whether it still holds.
The decision log in Nova
In Nova, every project has a Decision log tab. Session conclusions appear in it automatically, so when a meeting or async update ends with a conclusion, the decision is already logged. You can add other entries with Log an update, and download the whole log as a CSV file.
Each entry has a type and a severity. The types are Conclusions / Decisions, Wins / Achievements, Blockers / Delays reported, Critical issues logged, Deliverables shared and Date changes. Severities are Info, Warning / Monitor and Critical. So the log works as a decision log and a light issue log in one, and the project report collects the session conclusions for a client or your manager. See Track progress and report for the other project views.
Frequently asked questions
What is the purpose of a decision log?
A decision log keeps one record of what a team decided, why, and who decided it. It stops settled questions from being reopened, helps new people understand how the work got here, and shows stakeholders the reasons behind changes.
Who should own the decision log?
The person who made each decision is responsible for its entry, and one person, usually the project manager or chief of staff, checks the log weekly so it stays complete and readable.
What is the difference between a decision log and a RAID log?
A RAID log tracks risks, assumptions, issues and dependencies, the things that could affect a project. A decision log tracks only the decisions made and the reasons for them. Many projects keep both and link a decision to the risk or issue it resolves.
Should a decision log be in Excel?
A spreadsheet works for a single project with a few decisions a week. Once decisions come from many meetings and teams, it works better when decisions are logged where the meeting conclusions are written, so nobody has to copy them over.
How detailed should each entry be?
One sentence for the decision and two or three lines of context. Enough that someone who wasn't there understands what was decided and why, with a link to the full discussion if they need more.