Decision log template (free) + 5 filled-in examples

This is a decision log template you can paste into whatever tool your team already uses: a Markdown doc, a spreadsheet, a Notion database, a Confluence space, or a folder in the repo. The template comes first, then five filled-in examples, then the four rules that keep the log alive past its first month.

If your team lives in Confluence, there's a version of this built on Page Properties in the Confluence decision log template. For architecture decisions specifically, use the ADR template.

The template (Markdown)

One entry per decision. Copy this into a new doc or file each time.

# DEC-001: [The verdict, e.g. "Ship v1 without SSO"]

- **Status:** Proposed | Accepted | Superseded by DEC-0xx | Rejected
- **Owner:** @one-person
- **Decided on:** YYYY-MM-DD
- **Review by:** YYYY-MM-DD, or a trigger ("when we pass 50 enterprise leads"), or "none"
- **Area:** Product | Pricing | Engineering | Design | Ops | ...
- **Supersedes:** DEC-0xx (link), or "none"
- **Source:** link to the Slack thread, meeting notes, PRD, or ticket

## Decision
One or two sentences, phrased so someone could follow it as an instruction.

## Why
The reasoning and the constraint that forced the call.

## Options rejected
- Option A: why not
- Option B: why not

## Who agreed
@names. Note anyone who disagreed and committed anyway.

## What this changes
Docs, tickets, code, or other decisions that now have to follow this one.

The template (spreadsheet / register layout)

If you want a single-sheet register in Google Sheets or Excel, use these columns. Keep the long-form reasoning in a linked doc and put the link in the last column.

ID	Decision (verdict)	Status	Owner	Decided on	Review by	Area	Supersedes	Superseded by	Source link	Details link
DEC-001	Ship v1 without SSO	Accepted	Priya	2026-09-02	2027-01-15	Product	none		Slack thread	Doc

Add data validation on Status (a dropdown of the four values) and conditional formatting that highlights any row whose Review by date has passed. That one highlight does more for the log's health than any other formatting.

The template (Notion database properties)

Create a database called Decisions with these properties. Then make the Markdown template above the database's default page template, so every new row opens with the body sections filled in.

Property	Type	Notes
Name	Title	The verdict, e.g. "Ship v1 without SSO"
ID	Unique ID	Prefix DEC
Status	Status or Select	Proposed, Accepted, Superseded, Rejected
Owner	Person	Limit to one person
Decided on	Date
Review by	Date	Leave empty only if the decision is meant to be permanent
Area	Select	Product, Pricing, Engineering, Design, ...
Supersedes	Relation (to Decisions)	Turn on the two-way relation and name the reverse side "Superseded by"
Source	URL	Slack thread, meeting notes, ticket

Useful views: Open (Status is Proposed), Due for review (Review by is before today), and By area. If you're weighing whether Notion is the right home at all, see Notion alternatives for product decisions.

What each field is for

• ID. Lets people say "per DEC-014" in Slack, PRs, and tickets. Never reuse a number.
• Title as verdict. The title is what people scan and search. It should state what was decided, not what was discussed.
• Status. Proposed means not yet binding. Accepted means binding. Superseded means replaced, and must point to the replacement. Rejected means considered and declined, which is worth keeping so the same proposal doesn't get relitigated from scratch.
• Owner. The one person who made the call and who answers questions about it.
• Review by. A date or a trigger after which the decision should be re-checked. Temporary decisions without one become permanent by accident.
• Supersedes / Superseded by. The chain that turns a list of decisions into a history.
• Source. Where it was actually decided. Six months later, this link is often the most valuable field.
• Why / Options rejected. The part people skip and later regret. A decision without reasoning can't be safely revisited, because nobody knows which constraint it was protecting.

Five decision log examples

These are illustrative entries for a fictional B2B SaaS team, written the way a good entry reads. Swap in your own.

Example 1: Product

# DEC-011: Ship v1 without SSO

- **Status:** Accepted
- **Owner:** @priya (Head of Product)
- **Decided on:** 2026-09-02
- **Review by:** 2027-01-15, or earlier if 3+ enterprise deals stall on SSO
- **Area:** Product
- **Supersedes:** none
- **Source:** #product-v1 thread, 2026-09-02

## Decision
v1 launches with email + Google login only. SAML/SSO is out of scope for v1.

## Why
SSO is roughly three weeks of work, and none of the design partners
currently require it. The launch date is fixed by a partner commitment.

## Options rejected
- Build SSO before launch: pushes the date past the partner commitment.
- Buy a hosted SSO provider now: cost isn't justified before paying customers ask.

## Who agreed
@priya, @marco (Eng lead), @dana (Sales). Dana disagreed and committed.

## What this changes
Remove SSO from the v1 PRD. Sales says "on the roadmap" if asked, not a date.

Example 2: Pricing

# DEC-014: Price per workspace, not per seat

- **Status:** Accepted
- **Owner:** @sam (CEO)
- **Decided on:** 2026-09-20
- **Review by:** 2027-03-31
- **Area:** Pricing
- **Supersedes:** none
- **Source:** Pricing review meeting notes, 2026-09-20

## Decision
Paid plans are billed per workspace with a flat monthly price.
No per-seat charges on any plan.

## Why
The product gets more useful as more of a team joins. Per-seat pricing
pushes buyers to invite fewer people, which works against adoption.

## Options rejected
- Per seat: discourages inviting the whole team.
- Usage-based: hard for buyers to predict; billing work we can't afford yet.

## Who agreed
@sam, @priya, @dana.

## What this changes
Pricing page, billing integration, and the sales one-pager.

Example 3: Engineering

# DEC-017: Use Postgres as the job queue until 5k jobs/min

- **Status:** Accepted
- **Owner:** @marco (Eng lead)
- **Decided on:** 2026-10-01
- **Review by:** when sustained load passes 5k jobs/min
- **Area:** Engineering
- **Supersedes:** none
- **Source:** RFC-004 (link), PR #312

## Decision
Background jobs run on a Postgres-backed queue (SKIP LOCKED pattern).
No Redis or managed queue service for now.

## Why
We already operate Postgres. One less system to run, back up and monitor.
Current load is well under the threshold where this becomes a problem.

## Options rejected
- Redis-based queue: another stateful service to operate.
- Managed cloud queue: vendor lock-in and local-dev friction.

## Who agreed
@marco, @lee, @aisha.

## What this changes
New background work goes through the shared queue module. No new queues.

For an engineering call like this one, many teams also write an ADR in the repo. The decision log entry can just link to it.

Example 4: Design

# DEC-019: Onboarding is a checklist, not a product tour

- **Status:** Accepted
- **Owner:** @noor (Design lead)
- **Decided on:** 2026-10-08
- **Review by:** 2027-01-08
- **Area:** Design
- **Supersedes:** none
- **Source:** Figma file "Onboarding v2", design review notes

## Decision
New users see a dismissible 4-step checklist. No modal tours or tooltips
that block the UI.

## Why
In usability sessions, participants skipped the modal tour. A checklist
lets people explore and come back to setup steps when they're ready.

## Options rejected
- Modal product tour: blocks the UI and was skipped in testing.
- No onboarding: setup steps were missed without any prompt.

## Who agreed
@noor, @priya.

## What this changes
Remove the tour library from the frontend. Checklist steps map to events
so we can see where people drop off.

Example 5: A superseded decision

When a decision is reversed, you don't edit the old entry. You write a new one and mark the old one Superseded. Here is the pair.

# DEC-011: Ship v1 without SSO

- **Status:** Superseded by DEC-026
- **Owner:** @priya
- **Decided on:** 2026-09-02
...(original body left exactly as it was)...

# DEC-026: Add SAML SSO for the Business plan in Q1

- **Status:** Accepted
- **Owner:** @priya
- **Decided on:** 2026-12-10
- **Review by:** none
- **Area:** Product
- **Supersedes:** DEC-011
- **Source:** #sales-enterprise thread, 2026-12-09

## Decision
Build SAML SSO in Q1, available on the Business plan only.

## Why
DEC-011's review trigger fired: three enterprise deals stalled on SSO.
The original reasoning (no partner needed it) no longer holds.

## Options rejected
- Keep deferring: blocks deals already in the pipeline.
- SSO on every plan: support cost without matching revenue.

## Who agreed
@priya, @marco, @dana, @sam.

## What this changes
Q1 roadmap; Business plan feature list; security questionnaire answers.

Notice what the pair gives a future reader: the original reasoning, the trigger that changed it, and the new call, in order. That history is why you never overwrite.

The four rules that keep a decision log alive

1. The verdict goes in the title. "Ship v1 without SSO" is searchable and scannable. "SSO discussion" is neither.
2. Supersede, don't edit. A reversed decision gets a new entry. The old one is marked Superseded and linked, and its body stays untouched.
3. One owner per decision. A person, not a team. When the owner leaves, reassign their open decisions.
4. Every temporary decision gets a review-by date. A date or a trigger. Check the "due for review" list once a month.

I wrote more about why logs die in the first place, and it's rarely the template, in the engineering decision log post.

Where decision logs actually fail

A good template fixes structure. It doesn't fix capture. Someone has to notice a decision was made, leave the conversation, and file it. The big, meeting-shaped calls get filed. The "let's cut that from v1" in a Slack thread usually doesn't, and those are the decisions that get silently contradicted later.

That's the part Lockstep automates. It drafts entries in roughly this shape from Slack, Jira and Confluence, sends each to its owner for one-click approval, and briefs engineers and AI coding agents on the approved ones. You can keep this template as the format either way. If you're comparing options, see the decision log tools roundup.

Start small: file the last three decisions your team made using the template above, and put the register where people already look.