Decision Log Template: Stop Reopening the Same Business Decisions

Decision Log Template: Stop Reopening the Same Business Decisions

A decision log is a shared record of important choices: what was decided, who had authority, why the choice was made, what changes now, and when new evidence should trigger review. Use one row per decision. Keep it brief, link the evidence, assign follow-up, and never rewrite history.

Updated September 4, 2026

Teams rarely lose decisions because nobody attended the meeting. They lose them because the final choice disappears into chat, a recording, somebody's notes, or a task description that gets edited later. Three months pass. The original context fades. A new person joins. The same debate starts again.

That is not healthy reconsideration. It is organizational amnesia.

A decision log gives founders, operations leaders, project managers, and department heads one reliable place to answer five questions: What did we decide? Who made the call? Why did we choose it? What happens next? What evidence would justify reopening it?

The goal is not to record every conversation. It is to protect decisions that affect money, customers, scope, timing, risk, people, or the way work moves. A useful entry should take a few minutes to create and less than a minute to understand later.

This guide includes a copyable decision log template, a worked example, review rules, and a practical way to automate capture and follow-up without handing judgment to software.

What is a decision log template?

A decision log template is a consistent format for recording consequential choices as they are made. Each entry preserves the decision statement, accountable decision-maker, context, options considered, rationale, assumptions, affected work, follow-up actions, status, and review trigger.

Think of it as the organization's memory for choices, not a transcript of discussion.

Meeting minutes answer what happened in a meeting. A task list answers what somebody must do. A decision matrix helps compare options before choosing. A decision log answers what was finally chosen and why. Those records can link to one another, but they are not substitutes.

The distinction matters because a decision often outlives the meeting that produced it. A pricing change may affect sales scripts, invoices, forecasts, website copy, and customer communication. A vendor choice may shape costs and daily work for years. A decision to automate a process may alter roles, controls, and exception handling. The record must survive after the original participants move on.

McKinsey surveyed more than 1,200 respondents about organizational decision-making. Only 41 percent said their organizations made decisions aligned with corporate strategy and directed people and money toward high-value projects. Respondents at organizations that made and executed high-quality decisions quickly were twice as likely to report returns of at least 20 percent from their most recent major decision. Source: McKinsey, Good Decisions Don't Have to Be Slow Ones, published May 2019, captured September 4, 2026.

A decision log does not create good judgment by itself. It makes judgment visible. That visibility helps a team execute the choice, challenge it with evidence, and learn whether the expected result actually appeared.

What should you include in a decision log?

Use one row per decision and keep the summary compact. Link to longer evidence rather than copying an entire business case into the log.

Copy these prompts into a spreadsheet, shared document, project workspace, or database:

Decision ID:

Decision date:

Decision statement:

Status:

Accountable decision-maker:

People consulted:

Problem and context:

Options considered:

Rationale and evidence:

Assumptions and constraints:

Affected customers, teams, processes, systems, budgets, or policies:

Follow-up actions with owners and due dates:

Expected result and measure:

Review date or trigger:

Supersedes or superseded by:

Source meeting or document:

Last verified:

Do not add twenty more fields because the tool allows it. Every field adds capture effort. If entries become burdensome, people will record nothing and the perfect template will become an empty page.

Which decisions belong in the log?

Log a decision when forgetting its rationale would create meaningful cost, delay, conflict, risk, or rework. The choice does not need to be dramatic. It needs to have consequences beyond the person making it.

Good candidates include:

• Changing a price, package, discount rule, or payment term.
• Selecting or replacing a vendor, platform, or agency.
• Approving project scope, budget, timing, or a major trade-off.
• Changing who owns a customer, process, metric, or approval.
• Accepting a known risk or control gap.
• Pausing, cancelling, or prioritizing an initiative.
• Choosing what to automate and what must remain under human review.
• Approving an exception that may become a precedent.
• Changing a policy, customer promise, service level, or escalation rule.

Do not log routine actions that are already governed by an approved procedure. If a refund agent follows a documented rule to issue a standard refund, that is an execution record, not a new decision. If the manager approves a new exception that changes how future refunds should work, log it.

Use a simple threshold test. Create an entry when at least one statement is true:

1. Another team must change its behavior.
2. The choice commits money, time, reputation, or customer trust.
3. Reasonable people may ask why this option was chosen.
4. The choice depends on assumptions that may change.
5. Reversing it later would be expensive or disruptive.
6. The decision closes a debate that has already consumed time.

Avoid logging personal preferences and reversible micro-decisions. The font on an internal worksheet probably does not need a governance trail. A decision to remove a sales qualification step probably does.

How do you write a decision statement people can act on?

A strong decision statement names the action, scope, effective point, and owner. It should be readable without attending the original meeting.

Weak: We discussed lead response.

Better: We decided to improve lead response.

Useful: Effective September 11, Revenue Operations will own first response and routing for all website demo requests during US business hours; account executives retain opportunity ownership after qualification.

The useful version makes execution visible. It says what changes, who owns the change, which requests are included, and when the rule starts.

Write the decision in active language. Selected, approved, stopped, deferred, assigned, replaced, or retained are clearer than aligned on, agreed around, or moving forward with. If the sentence cannot be turned into a changed behavior, it may be an observation rather than a decision.

Keep rationale separate from the statement. The decision says what will happen. The rationale says why this option was chosen. Mixing both into one long paragraph makes the final choice hard to find later.

Record disagreement without turning the log into a courtroom transcript. A short note such as Finance preferred a longer pilot because cost data is incomplete preserves an important risk. It does not require documenting every exchange.

Most importantly, record the decision immediately. Microsoft analyzed aggregated Microsoft 365 activity and found that workers were interrupted every two minutes during core hours. Its global survey found that 48 percent of employees and 52 percent of leaders described work as chaotic and fragmented. Source: Microsoft WorkLab, Breaking Down the Infinite Workday, published June 17, 2025, captured September 4, 2026.

Memory is a poor storage system in that environment. If the recorder waits until Friday, the entry will preserve a simplified story rather than the actual context.

Who should own and update the decision log?

One role should own the log's health. That person does not make every decision and should not become the organization's permanent meeting secretary. Their job is to keep the system usable: consistent IDs, complete critical fields, working links, overdue reviews, and clear supersession history.

In a small company, the owner may be the operations lead. In a project, it may be the project manager. In a product team, it may be the product operations lead. In a leadership team, the chief of staff or general manager may maintain the central register.

Every entry still needs an accountable decision-maker. This is the person or governing group authorized to choose. Keep this separate from:

• Recorder: the person who writes the entry.
• Action owner: the person responsible for implementing a consequence.
• Consulted people: those who provide evidence, constraints, or expertise.
• Informed people: those who need to adjust after the choice.

Confusing those roles creates predictable failures. The recorder gets blamed for the decision. The action owner assumes approval has not happened. Everyone consulted believes they have veto power. People affected by the choice learn about it through a changed task instead of a clear communication.

Use a five-minute close at the end of the relevant meeting:

1. Read the decision statement aloud.
2. Confirm the accountable decision-maker.
3. Confirm the rationale and assumptions.
4. Name affected work and action owners.
5. Set the review trigger.
6. Share the entry with everyone affected.

This close is faster than another meeting next month to reconstruct what happened.

Asana's 2023 Anatomy of Work Global Index surveyed 9,615 knowledge workers across six countries. Respondents reported spending 58 percent of their day on coordination rather than skilled work and estimated that better processes could save 4.9 hours per week. Source: Asana Anatomy of Work Global Index 2023, published March 8, 2023, captured September 4, 2026.

A decision log should reduce that coordination tax. If maintaining it creates more administrative work than it removes, simplify the fields or narrow the threshold.

How is a decision log different from a decision matrix, RAID log, or meeting minutes?

These tools appear similar because they all organize project information. They operate at different stages.

A decision matrix helps before the choice. It compares options against weighted criteria. Use it when a team must choose among vendors, investments, locations, features, or operating approaches.

A decision log helps after the choice. It preserves what was selected, why, by whom, and under which assumptions. Link the completed matrix as evidence, but do not keep editing the matrix after approval to make the winner look inevitable.

A RAID log tracks risks, assumptions, issues, and dependencies. A decision may resolve an issue, accept a risk, validate an assumption, or change a dependency. Link the records so the consequence is visible.

Meeting minutes summarize discussion, updates, attendance, and actions from one session. A decision log collects decisions across many meetings and channels. The minutes may be the source; the log is the durable index.

A lessons-learned register records what the team learned from outcomes. A decision log records what the team believed before the outcome arrived. Comparing the two is valuable because it separates decision quality from luck. A sensible choice can produce a bad result because an assumption failed. A careless choice can produce a good result by accident.

A policy sets a standing rule. A decision log records the choice to create, change, or make an exception to that policy. The approved policy remains the source of truth for future work.

Wavicle already publishes separate guides for a decision matrix, risk register, project status report, and lessons learned. This template fills a different gap: the record that links the choice to its rationale, execution, measurement, and future review.

What does a completed decision log entry look like?

Imagine a 35-person services company losing warm leads because messages arrive through several forms and inboxes. Sales blames marketing. Marketing says the CRM assignment rules are unclear. The founder proposes buying another tool.

Here is the entry after the leadership team decides:

Decision ID: DEC-024

Decision date: September 4, 2026

Decision statement: Starting September 11, Revenue Operations will own the first response and qualification of all website demo requests during US business hours. Qualified requests will be assigned to account executives using the existing territory rules.

Status: Approved

Accountable decision-maker: Head of Sales

People consulted: Founder, Marketing Lead, Revenue Operations Lead, two account executives

Problem and context: Median response time is more than two hours. Some requests receive duplicate replies while others receive none. CRM territory ownership begins only after qualification, leaving first response unowned.

Options considered: Keep representative ownership, create a central RevOps queue, hire an external answering service, or buy a new lead-routing platform.

Rationale: The central queue fixes ownership with the current tools, adds business-hour coverage, and allows the team to test the process before buying software.

Assumptions: Revenue Operations has capacity for the expected daily volume. Existing CRM alerts are reliable. Most qualified leads can be routed using current territory rules.

Affected work: Website forms, shared inbox, CRM notifications, response scripts, dashboard, and sales service-level agreement.

Actions: Marketing Lead will route every form to the shared queue by September 9. RevOps Lead will publish the qualification checklist and coverage schedule by September 10. Sales Operations will add response-time reporting by September 11.

Expected result: Median first response below 15 minutes during covered hours, no unassigned requests, and fewer than 2 percent duplicate replies.

Review trigger: Review after 30 days or earlier if response time exceeds 30 minutes for five consecutive business days.

Supersedes: DEC-011, which assigned first response to account executives.

Notice what the entry does not contain: a transcript, a list of every comment, or a promise that the choice will work forever. It preserves enough context to execute and enough assumptions to review honestly.

It also prevents the company from buying automation before ownership is clear. The team first defines the queue, qualification rule, coverage window, exception path, and measure. Software can then support a working decision instead of hiding a broken one.

When should you review or reopen a decision?

Do not reopen a decision because somebody dislikes it, missed the meeting, or remembers the debate differently. Reopen it when new evidence changes a material assumption, risk, constraint, or expected outcome.

Good review triggers include:

• The expected measure misses a defined threshold.
• A customer, legal, safety, or financial risk changes materially.
• The budget or capacity assumption no longer holds.
• A dependency fails or a vendor changes its service.
• The decision's time limit expires.
• A new option becomes feasible at meaningfully different cost or speed.
• The operating environment changes enough that the original rationale no longer applies.

Bad triggers include seniority alone, a louder opinion, discomfort with accountability, or the arrival of a new person who has not read the record.

When a decision changes, do not edit the old entry until it tells the new story. Mark it superseded, create a new decision ID, and link both records. History is useful precisely because it shows what the team knew at each point.

Review decisions at a cadence that matches their consequence. A reversible workflow choice might need a 30-day review. A vendor contract may need review before renewal. A major pricing change may need weekly monitoring for the first month and quarterly review later. A standing policy may need an annual check plus event-based triggers.

Project Management Institute's 2024 Pulse of the Profession reported an average project performance rate of 73.8 percent across respondents and a 57 percent increase in the use of hybrid delivery approaches. Source: PMI, The Future of Project Work, published February 2024, captured September 4, 2026. The practical lesson is not that one method wins. It is that teams increasingly adapt how they work. A decision log lets them adapt without losing why the earlier choice made sense.

How can you automate a decision log without automating judgment?

Automate capture, routing, reminders, and reporting. Keep consequential judgment and approval with the accountable person.

A practical decision workflow can do the following:

• Detect an approved decision label in a meeting note, form, or project item.
• Create a draft log entry with the date, source link, participants, and proposed statement.
• Ask the decision-maker to confirm the statement, rationale, assumptions, and status.
• Create follow-up tasks with named owners and due dates.
• Notify affected people after approval.
• Remind the owner when an action or review is overdue.
• Pull the expected measure into a review view.
• Mark the prior entry superseded when a replacement is approved.
• Produce a weekly digest of new, overdue, and review-ready decisions.

Do not allow a meeting summary tool to declare a decision final without confirmation. Conversation includes proposals, objections, jokes, and hypothetical statements. A generated summary can help draft the entry; authority must remain explicit.

Start with the manual template for two weeks. Watch where entries originate, which fields people skip, how often decisions create tasks, and what reviews matter. Then automate the stable route. If you automate before the team agrees on the threshold and ownership, you will create a fast stream of unreliable records.

Wavicle helps non-technical leaders design this kind of operating workflow around the tools they already use. We map where decisions happen, define the minimum record, connect approval to follow-up, and add reminders and reporting only where they remove coordination work. Book a free growth consultation to review one decision-heavy workflow and identify what should remain human, what should be standardized, and what can be automated.

How do you launch the template this week?

Do not announce a company-wide governance program. Pick one decision-heavy team and prove the habit.

Day one: Choose the scope. A leadership meeting, client delivery program, product review, or operations team is enough. Name one log owner and one storage location.

Day two: Agree on the threshold. Use the six-question test from this guide. Show three examples of decisions that belong and three routine actions that do not.

Day three: Add the template to the meeting or work-management flow. Give every decision a stable ID. Make the source record easy to link.

Day four: Practice the five-minute close on a real decision. Read the statement aloud, confirm authority, assign actions, and set a review trigger.

Day five: Review the first entries. Remove fields that add no value. Fix vague statements. Confirm affected people received the decision.

After two weeks, measure whether the log is helping:

• How many consequential decisions were captured?
• How many entries have an accountable decision-maker?
• How many actions have an owner and due date?
• How many decisions were reopened without new evidence?
• How many overdue reviews exist?
• Can a person outside the original meeting explain why the choice was made?

The last question is the real test. A complete-looking row is worthless if it cannot restore context.

The system should become lighter as it improves. Repeated decision types may become policies, approval rules, or standard procedures. Repeated missing information may become required inputs. Repeated follow-up work may become an automated workflow. The log is not merely an archive; it reveals where the business still depends on memory and meetings.

Frequently Asked Questions

What is the purpose of a decision log?

A decision log preserves what was decided, who had authority, why the choice was made, which assumptions mattered, what actions follow, and when review is justified. It reduces repeated debate, lost context, unclear ownership, and decisions that never turn into execution.

What is the difference between a decision log and meeting minutes?

Meeting minutes summarize one meeting, including updates, discussion, actions, and attendance. A decision log collects consequential choices across meetings and channels. Minutes may link to the log as evidence, while the log remains the durable index of final choices.

Who should maintain the decision log?

Assign one operational owner to maintain structure, links, statuses, and review reminders. Each entry should separately name the accountable decision-maker, recorder, action owners, consulted people, and informed people. The log owner should not become responsible for everybody else's decisions.

What decisions should not go in the log?

Do not record routine actions already covered by a procedure, personal preferences, trivial reversible choices, or discussion that has not produced an approved direction. Log choices whose forgotten rationale would cause material cost, delay, conflict, risk, or rework.

How often should a decision log be reviewed?

Review new and overdue entries weekly in active teams. Review individual decisions on a date or event tied to their consequence. A 30-day operational experiment, a contract renewal, a missed performance threshold, or a material assumption change are better triggers than an arbitrary annual meeting.

Should you edit an old decision when the choice changes?

No. Mark the old entry superseded, create a new entry, and link them. Preserving the original context allows the team to understand what changed and prevents hindsight from rewriting the reasoning that existed at the time.

Can AI write decision log entries from meetings?

AI can draft an entry from notes or a recording, extract possible actions, and suggest missing fields. A person with authority should confirm the final statement, rationale, assumptions, status, and affected work. Generated text should assist capture, not manufacture approval.

What tool should you use for a decision log?

Use the simplest shared tool your team already checks: a spreadsheet, shared document, project workspace, or database. The right tool supports stable IDs, links, ownership, status, search, and review reminders. Adoption matters more than advanced features.

When is a decision log ready for automation?

Automate after the team has used the manual process long enough to define what belongs, who confirms entries, which actions follow, and what reviews matter. Automate draft creation, reminders, notifications, and reporting first. Keep material judgment and approval human.