How to keep a decision log that people still use after six months

By Meet Patel · 2026-10-03 · 6 min read

A decision log is a dated record of each significant decision, kept with its owner, the options rejected, the evidence used, the outcome expected and a date to check it. Teams that keep one can answer “why did we do that?” without relying on memory, and they can judge a decision later against what they believed when they made it.

Take a 25-person company (a hypothetical) that paused its outbound email campaign three months ago. A new sales lead asks why. Three people remember three different reasons: the budget, a poor reply rate and a data-quality problem. Each memory is sincere and none can be checked. The pause is reversed by whoever argues loudest, or the whole debate starts again from the beginning.

The log is a small fix for that situation. The hard part is keeping it alive, because a log started with enthusiasm can be abandoned within weeks. This post gives a template, a worked entry and the habits that stop a log from dying.

What a decision log is for

A log does three jobs, and it helps to know which one you are building for.

It stops settled questions from returning. A topic that closed without a record reopens every time someone new joins or someone senior forgets. The decisions a company never makes are expensive, and so are the ones it makes repeatedly.

It makes later reviews fair. Baruch Fischhoff's 1975 experiments found that people who were told an outcome judged it to have been more predictable than people who were not, and that they overestimated what they would have known beforehand. He called the effect creeping determinism. A review done a year later will be coloured by how things turned out. A record of what the team expected at the time is the practical defence against that.

It helps the next person. Software teams have kept architecture decision records for years. Michael Nygard's 2011 post on the practice says each record should be written “as if it is a conversation with a future developer.” That reader, a new hire or your own later self, is who the log serves.

How this differs from meeting notes

Meeting notes record a conversation in the order it happened, so a decision ends up buried in paragraph six of a Tuesday summary. A decision log is indexed by decision, so someone can search for “outbound” and find the pause, its reasons and its review date. The two work together. The notes hold the discussion, and the log holds the outcome with a link back to the notes. Teams that ask notes to do both jobs end up with long documents nobody searches, and their decisions can be recovered only by whoever attended.

The log also changes what people say in the room. When an owner knows they must state the options rejected and an expected outcome within minutes, vague agreements such as “let's look into it” show up as non-decisions. The meeting either decides, or it records honestly that it did not.

The seven fields

Keep the template short enough that nobody skips it. Seven fields cover what a later reader needs.

1. Decision. One sentence in full, in the active voice, such as “We will pause outbound email for eight weeks.” Nygard's format also asks for decisions to be stated in full sentences starting “We will.”
2. Owner. One named person, who is accountable for the decision and for writing the entry.
3. Date. The day it was made, which is different from the day it was discussed.
4. Options rejected. Each alternative that was seriously considered, with the reason it lost. This field prevents the most common re-argument, which is someone proposing an option that was already tried on paper.
5. Evidence. The figures and sources relied on, with dates, and a line stating what was unknown. A confident sentence is not an answer, and an entry without sources reads like one.
6. Expected outcome. A measurable statement with a number and a time frame. If the outcome cannot be measured, say what you will look at instead.
7. Review date. The day someone compares the expected outcome with the actual one.

Add a status line with one of three values: accepted, superseded or reversed. Nygard's format uses the same idea, with a status that can show a decision as superseded with a reference to its replacement.

A worked entry

Here is the pause from the opening, written as it would sit in the log. Every figure is illustrative.

Decision: We will pause outbound email to the small-business segment for eight weeks and move its budget to partner referrals.

Owner: Head of growth. Date: 14 October. Status: accepted.

Options rejected: Continue as is, because reply rate fell from 2.1 percent to 0.9 percent over three months. Switch email vendor, because migration takes six weeks and the cause of the decline is unclear.

Evidence: Reply-rate series from the CRM export, July to September. Unknown: cost per meeting by segment.

Expected outcome: At least 12 qualified meetings from referrals in eight weeks, at a lower cost per meeting than outbound's current $310.

Review date: 9 December.

That entry is about 110 words and should take about ten minutes to write. Both numbers matter. A future reader can see why the team chose referrals, and in December the team can test the 12-meeting prediction without anyone remembering what was hoped for.

Why decision logs die

Logs fail for a small number of ordinary reasons, and each has a repair.

• Entries take too long. If an entry takes thirty minutes, it will be skipped under pressure. Nygard's guidance is that a record should run to one or two pages at most. Aim for under 150 words and ten minutes.
• The log is written afterward, by someone else. Reasons reconstructed later are reasons invented later. The owner writes the entry in the last five minutes of the meeting where the decision is made.
• Everything is logged. A log with every small choice cannot be searched. Set a threshold, described below.
• It lives in several places. Notes in a chat thread, a document and a slide deck mean nobody trusts any of them. Pick one home.
• Nothing brings anyone back. Without a review date there is no reason to open an old entry, so the log becomes an archive nobody visits.
• Entries are edited afterward. If the log can be changed to match events, it stops being evidence. Entries are append-only. When a decision changes, write a new entry and mark the old one superseded. Nygard's guidance is the same: keep the old record and mark it as superseded.

How to set one up this week

1. Set the threshold. Log a decision when it is hard to reverse, when it affects more than one team, or when it has already been argued about twice. A decision that fits the one-way door category always qualifies. If you are logging more than a handful a week, raise the bar.
2. Choose one home. Use a shared table or document with one row per decision and a search box. Link to it from every set of meeting notes.
3. Fix the template. Copy the seven fields and the status line into the place where meeting notes are written, so the template is already in front of people when the decision happens.
4. Write it at the decision. The owner fills the entry in during the final five minutes of the meeting. The required fields are the decision, owner and date. The rest can follow within two working days.
5. Calendar the review. Put the review date in the owner's calendar when the entry is written, with a link to the entry.
6. Hold a monthly review. Spend thirty minutes opening every entry past its review date. Record the actual outcome beside the expected one, update the status, and write one line on what the team would do differently.

Check the log's health after a quarter

Three counts tell you whether the log is working. The first is the share of entries whose expected outcome contains a number and a date. The second is the share of reviews that happened within a week of their review date. The third is how many decisions were reversed within sixty days, which shows where the team decides too quickly or without enough evidence.

I would not set targets until you have a quarter of data, because any benchmark I could offer would be invented. The trend is what to watch. If the first two counts rise and the third falls, the log is changing how the team decides.

Write each entry for the person who will ask why in a year, and who will not remember the room.

Written by Meet Patel — startup operator and growth strategist in Dubai.

Read on themeetpatel.com