Decision Log Template: Fields, Formats, and an Example

A decision log is a running record of the choices your team makes: what you decided, why, who owns it, and when. This page gives you a template you can copy, a filled-in example, and a way to keep it current without turning it into another doc nobody updates.

If you want the case for keeping one at all, and how to make it build itself from meetings, read keep a product decision log automatically. This page is the template.

What a good decision log entry contains

An entry should answer the questions someone will actually ask three months from now. Keep it short. Six fields cover almost everything:

• Date. When the decision was made, not when you wrote it down.
• Decision. One sentence, in plain language.
• Why. The reason you picked this over the alternatives. This is the field people skip and the one they later wish they had.
• Owner. The single person accountable for it.
• Status. Decided, revisit by [date], or superseded by [link].
• Context. A link to the meeting, thread, or doc where it happened.

That is enough to settle a "wait, why did we do this?" without reopening the whole debate.

Decision log template (copy-paste)

Drop this into a table in Notion, a wiki, or a spreadsheet. One row per decision.

| Date | Decision | Why | Owner | Status | Context |
|------|----------|-----|-------|--------|---------|
|      |          |     |       |        |         |

If you prefer a block per decision over a table, use this:

### [Short decision title]
- Date:
- Decision:
- Why:
- Alternatives considered:
- Owner:
- Status: Decided | Revisit by [date] | Superseded by [link]
- Context: [link to meeting / thread]

The block format has room for "alternatives considered," which earns its place on the big calls (architecture, pricing, a key hire) and is overkill on the small ones.

A filled-in example

Here is what one row looks like with real content in it:

| 2026-03-12 | Use Stripe for billing, not Paddle | Paddle's merchant-of-record would cover EU VAT for us, but Stripe's API and docs are better and we already run it in test. VAT goes to a separate tax tool. | Andriy | Decided | Roadmap review, 2026-03-12 |

The "why" carries the trade-off, not just the choice. Six months later, when someone asks whether to switch, that one sentence saves an hour of re-arguing a settled call.

Which version fits your team

The fields stay the same. The scope changes.

A team decision log is broad: process changes, tooling, who owns what. Keep it in the wiki everyone reads.

A product decision log tracks feature and roadmap calls, what shipped, what got cut, and the reasoning behind each. Product managers live and die by this one. The product decision log guide goes deeper on it.

An architecture decision record (ADR) is the engineering version, usually one markdown file per decision kept in the repo, heavier on alternatives and consequences.

Pick the scope, reuse the six fields, and don't run three logs when one will do.

Keeping the template filled without the busywork

Templates don't fail because they're wrong. They fail because filling them in depends on someone remembering to, right after a meeting, when they're already late to the next one. So the log gets the decisions someone bothered to write down, in half-remembered words, missing the why.

The fix is to capture the decision where it happens, in the conversation. Nod records your meetings from your Mac's audio, with no bot in the call, and its summary pulls out a Decisions section on its own, next to action items and open questions. The decision, its owner, and the discussion behind it are there when the call ends, so filling the template is a copy step, not a memory test. Across a quarter the entries pile up into the log you meant to keep. And since you can ask across every meeting, "why did we choose Stripe?" returns the decision and the reasoning from whichever call it came up in. That cross-meeting recall is the AI meeting assistant part.

Audio is held in memory about five seconds, then dropped. Only the transcript and summary are saved, encrypted in the EU, with no model training. See meeting notes without storing audio for how that works.