Decision log template: how to record decisions so nobody re-litigates them — and where the log lives (2026)

A decision log is the running record of what a team has decided: one entry per decision, dated, with the decision stated in one sentence, the person or body that made it, the options that were on the table and the reason the chosen one won, what the decision rules out, and the condition under which it would be looked at again. It is not the minutes, and it is not the task list. It is the document someone opens three months later, when a new colleague asks "why do we do it this way?", and finds an answer instead of a meeting.

This guide is the craft first — what a decision log is, what every entry carries, how to write one before, during and after the meeting where the decision is made, a template and a register you can copy, three filled-in entries — then the mechanics: where the log lives in the tools your team already uses, and what of the decision actually gets into it. Because the log's real test is not the week it is written. It is the day someone says "I don't remember agreeing to that."

What a decision log is — and what it isn't

Four kinds of record come out of a meeting, and the decision log is the one most often confused with the other three:

The difference that matters: minutes are organized by meeting, the decision log is organized by decision. A decision made across three meetings has three minutes entries and one log entry. And the log keeps what minutes usually drop — the options that lost and the reason they lost — because that is the part the next argument is about.

A decision log is also not a policy manual. A policy is the current rule; the log is the history of how the rule got there, including the entries marked superseded. Keep both, link them, and never edit an old entry to match a new decision — add a new entry and point the old one at it.

What every entry carries: the format

Seven elements. Most templates online carry the first three and stop, which is why most logs get re-litigated:

1. An ID and a date. "D-14, 9 October". The ID is what people cite in chat ("that's D-14") instead of re-describing the decision and reopening it by accident.
2. The decision, in one sentence, in the present tense. "We quote in EUR only." Not "we discussed pricing"; not "it was felt that". If the sentence needs a paragraph, it is two decisions or none.
3. Who decided, who was consulted, who was told. One name or one body for the decision; the people whose input was taken; the channel or list that was informed. The first answers "who can change this"; the other two answer "was I asked" — the most common reason a decision is contested.
4. The options considered, including the one chosen. One line each. A log entry with a single option is a record of an outcome, not of a decision; the rejected options are what stop the same proposal coming back next quarter under a new name.
5. The reason the chosen option won. One line — the constraint, the number, the risk that settled it. This is the sentence that the new colleague is actually looking for.
6. Consequences: what changes, what it costs, what it rules out. The decision to quote in EUR only rules out a USD price list; say so, so that nobody builds one.
7. The revisit condition, and the source. The date, number or event that would legitimately reopen it ("if more than 10% of quotes are refused on currency"), and a link to where it was made — the meeting recap, the thread, the moment in the transcript. A decision with a stated revisit condition is reopened on evidence; a decision without one is reopened on mood.

What stays out: the discussion. Three paragraphs of who said what belong in the minutes or the transcript, and the log links to them. An entry is read by someone looking for one answer; it should fit on one screen.

How to write one: before, during, after

Before the meeting, put the decision on the agenda as a decision. The agenda item that will produce the entry is marked decision, with the question and the options already written: "Decide: EUR only, dual price lists, or USD on request — Lena, 15 min, decision." Half the entry exists before anyone speaks, and the room spends its minutes on the reason, not on reconstructing the options.

During the meeting, read the decision back before moving on. The facilitator says the sentence aloud, with the loser named: "so we're recording — EUR only, dual price lists rejected because of the maintenance cost, Lena decides, revisit if refusals pass 10%." The read-back is the moment the entry is actually made; the people who could object are in the room, and an objection now is cheaper than the same objection in six weeks. An item that cannot be read back as one sentence is not decided yet — it is marked open with the question that remains, and goes to the next agenda.

After the meeting, write the entry the same day and publish it where the team already reads. Copy the read-back sentence, add the options and the reason from the notes, give it an ID, link the recap. Then post it — in the channel where the meeting lives, not in one person's document. A log in a private folder is a log the team doesn't have, and a decision the team can't find is a decision it will take again.

The whole discipline is the read-back. The log is the read-back, written down.

A decision log template

One entry, for a document or a channel post:

D-[number] · [date] · [Decision in one sentence, present tense]
Status: proposed / decided / superseded by D-[number]
Decided by: [name or body] · Consulted: [names] · Informed: [channel or list]
Context: [two lines — the question, and why it had to be decided now]
Options: A — [one line]; B — [one line]; C — [one line]. Chosen: [letter]
Why: [the one constraint, number or risk that settled it]
Consequences: [what changes, what it costs, what it rules out]
Revisit if: [a date, a number or an event]
Source: [recap or thread link, and the moment]

The register, for the list that spans the year:

Both paste into a document, a spreadsheet, a canvas or a chat message without reformatting. The columns that are usually missing from templates are Rejected and Revisit if — the two that decide whether the entry is ever read again.

Three filled-in entries

A pricing decision — from the weekly

D-14 · 9 Oct 2026 · We quote in EUR only; a USD request gets the EUR price converted at the day's rate.
Status: decided
Decided by: Lena · Consulted: Anna, Mateusz · Informed: #sales
Context: Two distributors asked for USD quotes in September; maintaining a second price list was proposed.
Options: A — EUR only; B — dual EUR/USD price lists; C — USD on request, hand-converted. Chosen: A
Why: B doubles the maintenance of every price change; C has produced three inconsistent quotes already.
Consequences: No USD price list is built; the quote template says "EUR" in its header; refusals on currency are counted.
Revisit if: more than 10% of quotes in a quarter are refused on currency.
Source: Weekly, 9 Oct, recap item 2, 14:05.

A hiring decision — from a one-off meeting

D-15 · 10 Oct 2026 · The second support hire is in Lisbon, Portuguese- and Spanish-speaking, not a second person in the Milan office.
Status: decided
Decided by: Tomás · Consulted: Priya, Dana · Informed: #team
Context: Support tickets from Spain and Brazil passed 40% of the queue in Q3.
Options: A — second hire in Milan; B — hire in Lisbon; C — outsource Spanish support. Chosen: B
Why: C was rejected on handover quality in the pilot; A leaves the Spanish queue where it is.
Consequences: The job post is in Portuguese and Spanish; onboarding happens remotely; the team's working language in the support channel stays mixed.
Revisit if: the Spanish and Portuguese share of tickets falls below 20% for two quarters.
Source: Hiring call, 10 Oct, recap item 3.

A decision superseded

D-9 · 14 Aug 2026 · Client calls are recorded by default.
Status: superseded by D-16
D-16 · 13 Oct 2026 · Client calls are recorded only when the client has agreed in the invitation; the recap is written either way.
Decided by: Lena · Consulted: Kenji (legal), Anna · Informed: #sales, #team
Options: A — keep recording by default; B — ask in the invitation; C — stop recording clients. Chosen: B
Why: two clients objected in September; the recap, not the recording, is what the team actually reads afterwards.
Consequences: The invitation template gains one sentence; D-9 is closed, not deleted.
Revisit if: a client contract requires recordings.
Source: Weekly, 13 Oct, recap item 1, 03:40.

Notice what the three have in common: a sentence a stranger can act on, the loser named with its reason, and a condition that says when the question is legitimately open again. That is the whole craft. Everything else in this guide is about keeping that entry findable after the meeting ends.

Why decisions get re-litigated

Teams rarely reopen a decision because they disagree with it. They reopen it because the record cannot answer one of four questions:

• "Did we actually decide that?" The outcome was discussed but never read back, so each person left with their own version. The fix is the read-back, not a better document.
• "Why did we decide that?" The sentence survived, the reason didn't. Six weeks later the reason is unknown, the decision looks arbitrary, and the proposal that lost comes back as if it were new. The fix is the Why and Rejected lines.
• "Was I asked?" Someone affected was not consulted or not told, and contests the decision to be heard rather than to change it. The fix is the Consulted and Informed lines — and publishing the entry where that person reads.
• "Has anything changed?" A decision with no revisit condition is reopened whenever someone feels like it; one with a condition is reopened when the condition is met, and otherwise cited by ID. The fix is the Revisit if line.

A log that carries all seven elements closes all four questions. One that carries only the sentence closes the first and opens the other three.

Where the decision log lives in the tools you already use

Each major platform has a place where a decision can be written down, and each stops at a different point. Documented behaviour only, from the vendors' own pages, with the month each page was checked:

Two things are the same everywhere. The decision is a line a person types into a document next to the meeting, in the one language the room used; and the reason, the rejected options and the moment it was said are in the document only if that person wrote them down.

How a decision comes back as the recap

InterMIND is a communication space where a meeting lives in a channel, so the log has an obvious home: the channel's chat, where the agenda went in the day before and the entries are posted after — and where each member types in their own language and reads the others in theirs. If the register is kept somewhere else, a spreadsheet or a document, its updates can land in the channel by email: the channel's host gives it an address of its own, and a message sent there appears as a regular message with the sender named and attachments kept.

During the call, the entry under discussion goes on everyone's screen next to the video tiles with Share to conference: the sharer edits the note live while the room watches the read-back take shape, and every participant reads it in their own language, with the original a toggle away.

When the call ends, the recap is written from the meeting itself. It carries an overview and key takeaways, then the points — each marked agreed, open or disputed, with the speakers attached and a timestamp that opens the transcript at the moment it was said — then the action items with owners and the open questions. That is the raw material of a log entry: the sentence, who said yes, who disagreed and where, and the moment to link as Source. The recap arrives by email, as a message in the channel and as a link in the calendar event, and every signed-in member reads it in their own language — the record is translated per reader, not written once in the language the room happened to use. Any member can edit it, every edit keeps author and revision history, and the channel keeps the recap of every past session, so the meeting where D-14 was made is one click away from the entry that cites it.

Where the entry has to end up in a system of record, the host adds a recap copy to any address — a CRM or tracker inbound mailbox — and every recap of the meeting or channel is also sent there after a one-time confirmation of the address; the mechanics are in a copy of every meeting recap in your CRM, by email. The same recap reaches Zapier, a webhook or the API with the summary as Markdown, and a member's own assistant — Claude, ChatGPT, Copilot or Gemini — can search the recaps through the MCP connector, so "what did we decide about USD quotes?" is a question asked in the tool they already use, answered with the recap and its moment.

A guest joins by link, without an account and at no cost — from a phone, in the browser — and hears the meeting live in their own language. There is no record for a guest afterwards — the account is free, and it is what makes the record reachable. The host provides the space and, on a paid plan, pays only for the members active in the previous 28 days; members who go quiet keep their access at no cost.

• Open a complete recap — a real record rendered by the same code that writes yours, points and timestamps included.
• Try the live demo — no signup; speak, and hear the room translated per listener.

Decision logs as a craft survive every tool: somebody still has to say the sentence aloud, name the option that lost, and write down when the question may be asked again. What doesn't have to survive is the second job — reconstructing who agreed to what from memory, in one language, for people who read others.

FAQ

What is a decision log?

A decision log is the running record of a team's decisions, one entry per decision: the decision in one sentence, the date, who made it, who was consulted and informed, the options considered and the reason the chosen one won, what it rules out, the condition that would reopen it, and a link to where it was made. It is organized by decision, not by meeting, which is what makes it different from minutes.

What should be included in a decision log?

Seven things per entry: an ID and a date; the decision in one present-tense sentence; who decided, who was consulted and who was informed; the options considered, including the rejected ones; the reason the chosen option won; the consequences — what changes and what is ruled out; and the revisit condition plus a link to the source. The two most often left out are the rejected options and the revisit condition, and they are the two that stop a decision from being re-opened.

How do you write a decision log?

Put the decision on the agenda as a decision, with the options written in advance. In the meeting, read the decision back aloud before moving on — the sentence, the loser and its reason, who decides, when it is revisited. The same day, write the entry from the read-back, give it an ID, link the recap, and post it where the team already reads. A log that is written from read-backs is accurate; one reconstructed a week later from memory is the start of the next argument.

What is the difference between a decision log and an action log?

A decision log records what was decided and why; an action log — or an action items list — records what someone will do because of it, with an owner and a date. "We quote in EUR only" is a decision; "Anna — update the quote template to EUR — by 16 October" is the action it produced. Decisions are cited for months; action items are closed in days. Keeping both in one list is how the reasons get lost under the tasks.

What is a decision register?

The same thing as a decision log, in the vocabulary of project and governance work: a table with one row per decision — ID, date, decision, who decided, why, status. "Register" tends to mean the tabular view and "log" the running one; the table in this guide is both, with Rejected and Revisit if added to the usual columns.

Is there a decision log template in Excel or Word?

The register in this guide is a plain table and the entry is plain text; both paste into Excel, Google Sheets, Word, a Slack canvas, a Loop page or a chat message without reformatting. The format matters more than the file: whatever holds the log needs a row per decision with the reason and the rejected options, and it needs to live where the team already reads.

Who should keep the decision log?

The facilitator of the meeting where the decision is made writes the entry, the same day, from the read-back; the person named under Decided by owns the decision itself. In a small organization that is usually the same person for most entries. What matters more than the role is the place: one log for the team, in the channel the team already uses, not one per person.

What is an architecture decision record?

An architecture decision record, or ADR, is the software-engineering form of a decision log entry: one short document per decision, kept in the project's repository, with the context, the decision, and its consequences, and a status that moves from proposed to accepted to superseded. The template in this guide is the same idea for a team's operating decisions, with the people — who decided, who was consulted, who was told — added, because outside engineering that is what gets contested.

Sources: Microsoft — Take meeting notes in Microsoft Teams; Zoom — Using Meeting Summary with AI Companion; Google Meet — "Take notes for me" in Google Meet; Google Workspace Updates — "Take notes for me" now captures "next steps"; Slack — Meeting agenda template (canvas). Microsoft's notes page, Google's Meet help page and Slack's template checked October 2026; Zoom's meeting-summary page checked August 2026; Google's next-steps announcement checked September 2026. Vendors change plans, features and language lists over time; check their pages for the current state.