Teams rarely reopen old decisions because they enjoy repeating themselves. They reopen them because the original decision disappeared into a meeting recording, a private chat, an email thread, or somebody’s memory. A month later, a new stakeholder asks why the team chose one option over another, and the discussion begins again from zero.
A decision log prevents that cycle. It is a lightweight record of what was decided, who owns the next action, when the decision was made, and what evidence or constraints shaped it. Done well, it does not create more administration. It removes repeated meetings, conflicting instructions, and the awkward question: “Didn’t we already agree on this?”
The goal is not to document every conversation. The goal is to make decisions easy to find, understand and act on.
What a decision log is—and what it is not
A decision log is a running list of decisions that materially affect work. It can live in a spreadsheet, project tool, shared document or knowledge base. The format matters less than consistency.
Each entry should answer five practical questions:
- What was decided?
- Why was this option chosen?
- Who made or approved the decision?
- What happens next, and who owns it?
- When should the decision be reviewed, if ever?
A decision log is not a meeting transcript. It should not capture every opinion, side discussion or sentence. It is also not a task list, although a decision may create tasks. Think of it as the permanent bridge between a discussion and the work that follows.
Why teams keep debating the same issues
Most repeated debates come from one of four gaps.
The decision was never stated clearly
A meeting ends with phrases such as “Let’s move forward,” “We’re aligned,” or “That sounds good.” Everyone leaves with a slightly different interpretation. One person thinks the launch date is fixed. Another thinks it is still a target. A third thinks the team only approved further investigation.
A useful decision is specific enough to act on. “We will launch the pilot to 50 customers on September 15 using the current onboarding flow” is a decision. “We will move forward with the pilot” is not.
The reasoning was lost
People remember the outcome but forget the constraints. Six weeks later, the rejected option looks attractive again because nobody remembers that it depended on unavailable engineering capacity or would have delayed a contractual deadline.
Recording two or three lines of rationale protects the team from judging an old decision with incomplete context.
The owner was unclear
A group can agree on a direction without anybody becoming responsible for the next step. The decision then sits untouched until someone notices the delay. A decision log should always name an owner for the immediate follow-through, even when several teams are involved.
The record was impossible to find
A perfect note hidden in a private folder is not a useful record. The log needs one stable location, predictable labels and links back to the relevant project material. If your team already struggles to find information, the principles in Building a Personal Knowledge Base for Work can help you keep the system small and searchable.
The seven fields every decision-log entry needs
You can build a dependable decision log with seven columns or headings.
- Decision ID: a simple identifier such as DEC-024.
- Date: when the decision became effective.
- Decision: one clear sentence describing the approved direction.
- Reason: the main evidence, trade-off or constraint.
- Decision maker: the person or group with authority to approve it.
- Action owner: the person responsible for the immediate next step.
- Status or review date: active, superseded, reversed, or scheduled for review.
Add links to supporting material when useful, but keep the entry understandable without opening five documents. The log should explain the decision at a glance; the links provide depth when somebody needs it.
A practical example
Imagine a team deciding whether to delay a software release for one additional feature. A weak note might say:
Team agreed to keep the original launch.
A useful decision-log entry would look like this:
Decision: Release version 2.4 on August 18 without the advanced export feature. Reason: The feature requires another two weeks of testing, while three contracted customers depend on the August release date. Decision maker: Product Director. Action owner: Product Manager to move advanced export into version 2.5 and notify customer success by July 30. Status: Active; review only if a critical defect appears before release.
This entry is short, but it prevents several future problems. Sales knows what to promise. Engineering knows what is out of scope. Customer success knows when to communicate. A new stakeholder can understand why the team did not wait.
How to capture decisions during a meeting
Do not wait until the next day to reconstruct what happened. Capture the draft decision while the meeting is still running.
Listen for decision language
Common signals include:
- “We are choosing…”
- “The final approach is…”
- “We will not…”
- “For this phase, we are limiting…”
- “The owner will be…”
When the conversation sounds settled, pause and confirm the wording: “Let me capture the decision. We are keeping the August 18 launch, moving advanced export to version 2.5, and Maya owns the customer update. Is that accurate?”
This is where precise meeting questions matter. The method in How to Ask Smart Questions in Meetings helps turn vague agreement into an answer with a date, owner and consequence.
Read the decision back before the meeting ends
A 20-second read-back is cheaper than a second meeting. It gives participants a final chance to correct the wording and reveals hidden disagreement. If nobody can approve the sentence, the team has not actually made a decision.
For meetings that begin without a clear purpose, use the recovery tactics in How to Handle Meetings With No Agenda and identify the decision the group needs before the discussion expands.
How to keep the log useful instead of bureaucratic
Record only consequential decisions
Do not log the choice of font for a routine slide deck. Log decisions that affect scope, budget, deadlines, ownership, policy, customer commitments, technical direction or significant risk.
A simple test is: could a reasonable person question this choice later, and would the answer affect work? If yes, record it.
Use one sentence for the decision
The first line should stand alone. Put background and rationale in separate fields. When the decision sentence becomes a paragraph, it usually contains several decisions that should be separated.
Never overwrite history
When a decision changes, mark the old entry as superseded and link it to the new one. Do not silently rewrite the original. The change itself is valuable information, especially when teams review project outcomes later.
This makes retrospectives more useful because the team can compare assumptions with results. See How to Run a Project Retrospective That Drives Change for a practical way to turn that evidence into improvements.
Assign a log owner, not a decision owner
One person should maintain the log’s structure and quality. That person does not approve every decision. They make sure entries are complete, links work, statuses are updated and duplicate records are merged.
For a small team, this may be the project manager or meeting facilitator. For larger programmes, each workstream can maintain its own entries while following the same template.
Turn the decision log into better status communication
A decision log should not sit apart from weekly reporting. Use it to make status updates more useful.
Instead of reporting only completed tasks, include:
- new decisions made this week;
- decisions waiting for approval;
- decisions that changed scope, cost or timing;
- older decisions approaching a review date.
This gives managers visibility without forcing the team to retell the full story. It also helps you communicate progress without repeatedly chasing people. The structure in How to Communicate Project Status Without Being a Nag pairs well with a decision log because both focus on clear ownership and concrete next steps.
A 10-minute setup you can use today
Create a shared table with the seven fields above. Add the five most important decisions from your current project—not every past conversation. Then invite the team to correct anything inaccurate.
At the end of each decision-making meeting, spend one minute adding or updating the relevant entry. Review open and recently changed decisions during your weekly project check-in. Archive the log with the project when the work closes.
The system works when people trust it as the place to answer: “What did we decide, and why?” Once that answer becomes easy to find, repeated debates shrink, handoffs become cleaner and new stakeholders can join without forcing the team to replay months of context.
Conclusion
A decision log is one of the smallest systems that can remove a surprising amount of workplace friction. Keep it concise, record the reasoning, name the owner and preserve changes rather than rewriting history. You are not documenting meetings for their own sake. You are giving the team a durable memory—and protecting future work from yesterday’s uncertainty.