Skip to main content

Work

Decision Log Template

A decision log is a running record of what was decided, why, by whom, and what you expected to happen. This template adds the two fields most logs leave out: who disagreed, and a date to check whether the decision worked. Copy it for a team, or use the decision journal example for your own choices.

Updated 2026-10-27

Copy and adapt

The template

Decision logTemplate

Decision log: [team or project]

Keeper: [one name, logs each decision within a day] Who reads this: [teams, new joiners, auditors] Related: [[Project name]]

Index

IDDateDecisionStatus
D-001YYYY-MM-DD[Short title]Active

D-001: [Short decision title]

Date: {{date}} Status: [Proposed / Active / Superseded by D-00X / Reversed] Decided by: [one name, or a named group and how it voted] Input from: [names] Affects: [teams, customers, systems, budget]

Context: [What forced a decision now: the constraint, the numbers, the deadline]

Options considered:

  1. [Option], rejected because [reason]
  2. [Option], rejected because [reason]
  3. [Chosen option]

Decision: [One sentence that someone new could act on] Why: [The reason in one to three sentences] Dissent: [Who disagreed and what they predicted. "None" is an answer] Expected outcome: [What we should see, and by when, if this was right] Revisit: @remind(YYYY-MM-DD 09:00), or sooner if [trigger]

Next steps:

  • [Action] (@[owner]) @due(YYYY-MM-DD)

5 examples

Examples for different situations

The same structure, filled in for the situations people actually bring to it. Copy the one closest to yours.

1.Switching a vendor in a small business

When it fits: Use this when a cost or contract change forces a decision that touches everyone's paycheck or workflow, and you want the reasoning on record before the first complaint arrives.

Switching a vendor in a small businessExample 1

D-014: Move payroll to Ledgerly from January

Date: 2026-10-22 Status: Active Decided by: Helen Park (practice manager) Input from: Sam Ortiz (outside accountant), the three clinic leads Affects: all 42 staff across three clinics, the Jan 9 pay run

Context: Our current payroll provider raises its fee from $6 to $9 per employee per month on Jan 1, an increase of about $1,500 a year. The contract renews on Dec 31 and needs 30 days' notice, so we must decide by Dec 1.

Options considered:

  1. Stay and pay the increase, rejected because the price rises with no new features and support tickets take four days.
  2. Crewpay, rejected because it cannot split one employee's hours across two clinics, which 9 of our staff need.
  3. Ledgerly, chosen.

Decision: Move payroll to Ledgerly for the Jan 9 pay run; the current provider runs December as usual. Why: Ledgerly handles split-clinic hours, costs $7 per employee, and Sam already uses it for two other clients. Dissent: Dr. Amari (Westside lead) worried that a January switch collides with year-end tax forms. Agreed: the current provider issues 2026 forms, Ledgerly starts clean in 2027. Expected outcome: First pay run on time with zero manual corrections; saves about $1,000 a year compared with staying. Revisit: @remind(2027-02-15 09:00), after two pay runs, or sooner if a pay run is late

Next steps:

  • Send the 30-day notice in writing (@Helen) @due(2026-11-14)
  • Export employee records and bank details (@Helen) @due(2026-11-28)
  • Parallel test run on December hours (@Sam) @due(2026-12-19)

2.Engineering decision with recorded dissent

When it fits: Use this when a technical choice is made over a reasonable objection, and the objection should stay visible so the team can tell in three months who was right.

Engineering decision with recorded dissentExample 2

D-031: Run nightly jobs on the queue workers, retire the cron VM

Date: 2026-11-03 Status: Active Decided by: Priya Raman (tech lead), after the architecture review Input from: Marta Silva, Jonas Weber, Leo Tran (on-call lead) Affects: the billing export, the cleanup job and the weekly report job; on-call runbook

Context: The three nightly jobs run from cron on one VM. It failed silently twice in October (Oct 9 and Oct 24), and the billing export missed a run each time; finance found out four days later.

Options considered:

  1. Keep cron, add a heartbeat alert, rejected because it fixes detection but not the single machine.
  2. A managed scheduler service, rejected because it adds a new vendor and a second deploy path.
  3. Schedule the jobs on the existing queue workers with retries and failure alerts, chosen.

Decision: Move all three jobs to the queue workers by Nov 20 and shut down the cron VM on Nov 27. Why: The workers already run on three machines, already have alerting, and are deployed with the rest of the app. Dissent: Marta disagreed. Her prediction: long jobs will compete with user-facing work and slow the 02:00 to 03:00 traffic. Agreed check: p95 queue latency in that window stays under 2 seconds. Expected outcome: No missed nightly run in December; p95 queue latency at 02:00 under 2 s. Revisit: @remind(2027-01-05 10:00), or immediately if latency passes 2 s on three nights

Next steps:

  • Port the billing export first (@Jonas) @due(2026-11-13)
  • Latency dashboard for the 02:00 window (@Marta) @due(2026-11-10)
  • Update the on-call runbook (@Leo) @due(2026-11-20)

3.Reversing an earlier decision

When it fits: Use this when a decision you logged is being undone, and you want both entries to point at each other so nobody finds the old one and acts on it.

Reversing an earlier decisionExample 3

Index (excerpt)

IDDateDecisionStatus
D-0092026-03-02Four office days a weekSuperseded by D-022
D-0222026-10-26Two fixed team days a weekActive

D-022: Two fixed team days, replacing four office days

Date: 2026-10-26 Status: Active, supersedes D-009 Decided by: leadership group (Nadia, Chris, Ewa), unanimous Input from: all-staff survey (51 of 60 replied), team leads Affects: all 60 staff, desk booking, the lease renewal in June 2027

Context: D-009 expected better collaboration and full desks. Since March, five people have resigned and four named the commute in their exit interview. Desk occupancy averages 48 percent; most people come in on different days, so teams rarely overlap.

Options considered:

  1. Keep four days and enforce them, rejected because enforcement would cost more people.
  2. Fully flexible, rejected because the survey's top complaint was never seeing teammates.
  3. Two fixed days per team, chosen.

Decision: From Nov 16, each team has two fixed office days (design and strategy Tue and Wed, delivery Wed and Thu). Other days are optional. Why: Same-day overlap was the goal of D-009; fixed days get it with half the commuting. Dissent: None in the group. Two team leads would have preferred three days. What we learned from D-009: we measured attendance, not overlap. Overlap is now the measure. Expected outcome: At least 80 percent of each team in on its fixed days by January; no commute-related exits in the next six months. Revisit: @remind(2027-02-01 09:00), and before the lease decision in April

Next steps:

  • Change D-009's status and link it here (@Nadia) @due(2026-10-27)
  • Announce at the Nov 2 all-hands (@Chris) @due(2026-11-02)

4.Personal decision journal with a six-month review

When it fits: Use this for your own decisions, when you want to judge later whether the choice was good or just lucky, by writing down what you expected before you knew the result.

Personal decision journal with a six-month reviewExample 4

Decision journal: stop weekend freelance work

Date decided: 2026-04-20 Decided by: me Input from: Ana (partner), Dev (friend who quit freelancing last year)

Context: Freelance design work on weekends brings about $1,100 a month. I have worked 9 of the last 10 weekends. Sleep averages under 6 hours on Sundays, and I said no to my sister's wedding planning trip because of a deadline.

Options considered:

  1. Keep going as is, rejected; this is what I am trying to fix.
  2. Cut to one client, rejected because the one I would keep is the most demanding.
  3. Stop entirely after finishing current projects in May, chosen.

Decision: Finish the two current projects by May 31, take no new freelance work for six months. Why: The money pays for extras, not rent, and the cost is every weekend. How I felt deciding: tired, a little guilty about the money, relieved once I wrote it down. Confidence: 70 percent that I will not regret it. Expected outcome: Savings rate drops from 18 to 12 percent. Weekends free at least three out of four. I start the ceramics course. Revisit: @remind(2026-10-20 19:00)

Review, 2026-10-20

  • What happened: Savings rate dropped to 13 percent. Free on 21 of 24 weekends. Did the ceramics course, now on the second term.
  • What I did not expect: My day job got better. I pitched and led the October rebrand, which I would not have had the energy for in April.
  • Good decision or good luck? Good decision. The cost was what I predicted, and the benefit was larger.
  • Next: Keep it. Reconsider one small project a year if the rate is high and the work is interesting.

5.Volunteer board decision taken by vote

When it fits: Use this when a committee or board votes, the minority view should be on record, and next year's volunteers will need to know why the change was made.

Volunteer board decision taken by voteExample 5

D-007: Replace the spring gala with a family fun run

Date: 2026-10-21 Status: Active Decided by: Lincoln Elementary PTA board, vote 7 for, 2 against Input from: fundraising committee, school principal, parent survey (212 replies) Affects: the April 25, 2027 fundraiser, sponsor outreach, volunteer roster

Context: The 2026 gala grossed $31,000 but cost $16,800 (venue, catering, auction platform), netting $14,200. It needed 40 volunteers, and 61 percent of survey replies said tickets at $85 were too expensive to attend.

Options considered:

  1. Keep the gala, rejected because of cost and the volunteer load.
  2. Online auction only, rejected because it raised the least of any event in 2023.
  3. Fun run with pledges and business sponsors, chosen.

Decision: Hold a 2K family fun run on April 25, 2027 at the school field, with per-lap pledges and sponsor banners. Why: Projected costs of about $4,000 (shirts, permits, timing) against a target of $22,000 gross, and every family can take part. Dissent: Greg Lin and Maria Costa voted against. Their prediction: corporate sponsors who gave $5,000 at the gala will not sponsor a fun run, and net will fall below last year. Expected outcome: Net at least $15,000; at least 60 percent of families register. Revisit: @remind(2027-05-05 18:00), at the May board meeting, with the final numbers

Next steps:

  • Ask the two largest gala sponsors directly (@Greg) @due(2026-11-20)
  • Field and permit booking (@Principal Ruiz) @due(2026-12-01)
  • Draft the pledge form (@Maria) @due(2027-01-15)

What goes in a decision log entry

A decision log template needs a small set of core fields: date, decision, rationale, who decided, options considered, status. The template above has all of them, and each one has a job:

  • Context. The constraint that forced a decision now. Without it, the decision looks arbitrary to anyone who joins later.
  • Options considered, each with a reason for rejection. This is the field that stops relitigation. When someone proposes the rejected option in six months, the answer is already written.
  • Decided by. One name or a named group and how it voted. "We decided" hides who is accountable.
  • Affects. Who has to change what they do. It doubles as the list of people to tell.
  • Next steps. A decision with no owner and date is a statement of intent.

The template adds three fields that most decision logs leave out, and they are the ones that make a log worth reading a year later.

Dissent, expected outcome and revisit

Dissent. Write who disagreed and what they predicted would go wrong. It costs one line. It makes people more willing to commit to a decision they argued against, because the objection is on record, and it gives the revisit something specific to check.

Expected outcome. What you should see, by when, if the decision was right. "Billing export never misses a run in December." "Net at least $15,000." Written before the result, it separates good decisions from lucky ones.

Revisit. A date, plus a trigger that would bring the review forward. Most logs only record decisions going in. A revisit date means each entry gets checked once against what actually happened.

Superseding and reversing decisions

Decisions change. The log should show that, not hide it.

  1. Never edit or delete the old entry. Change its status to "Superseded by D-022" and leave the text alone.
  2. The new entry names the old one in its status line and says what was learned. The reversal example above records that the first decision measured attendance when the goal was overlap.
  3. Keep the index current. The index is what people scan. A superseded decision with an "Active" status in the index is how teams act on rules that no longer exist.

Which decisions belong in the log

Log a decision when it costs money, changes how other people work, is hard to reverse, or is likely to be questioned later. Skip choices that can be undone next week at no cost. If you are unsure, write one line in the index and the short version of the entry. A log with 300 trivial entries hides the twenty that matter, and a log with three entries is not being used.

The personal decision journal

The same structure works for your own choices: changing jobs, moving, quitting a side project. A decision journal adds two lines: how you felt when deciding, and how confident you were. At the review, compare the expected outcome with what happened and ask whether the result came from the decision or from luck. Over a year, the pattern of your misses tells you more than any single entry.

Common mistakes

  • Logging only the winner. Without the rejected options, the log cannot answer the question people actually bring to it.
  • "The team decided." Name a person or a group and the vote.
  • No revisit date. The decision is never checked, so the log never teaches anything.
  • Editing history. Overwriting an old decision erases the reason you changed your mind.
  • Keeping it in one person's head or inbox. The log is for the people who were not in the room. Share it where they can find it.

Customization tips

  • Log the decision within a day

    A decision written up a week later loses the options that were rejected and the numbers that drove it. Give one person the keeper role and a 24-hour rule. Five minutes after the meeting is enough.

  • Write the expected outcome before you know it

    This is the field that turns a log into something you learn from. Without it, every decision looks obvious in hindsight, good or bad. With it, the revisit is a comparison, not a story.

  • Never delete or edit an old decision

    When a decision changes, add a new entry and set the old one's status to Superseded by the new ID. The history of why you changed your mind is often more useful than either decision on its own.

  • Record dissent with a prediction

    "Marta disagreed" is a note. "Marta predicted queue latency above 2 seconds" is a test. Dissent written as a prediction is checked at the revisit, which is fairer to the person who objected and settles the argument with data.

  • Keep the bar for logging low but specific

    Log anything that costs money, changes how other people work, or that someone is likely to ask about later. Skip choices that are easy to reverse next week. One line in the index is fine for small decisions; the full entry is for the rest.

  • For a personal decision journal, add how you felt

    Tired, rushed, angry and relieved all change decisions. A line about your state at the time, plus a confidence percentage, makes the six-month review honest about whether the process or luck produced the result.

In the app

How to do this in Scribelet

  1. Open Desk Settings, then Templates, tap Add Template and paste the template above. Set the category to General for a team log, or save the journal version under Journal for personal decisions.

  2. Keep the index in one log note and write each decision as its own note linked with [[Decision log: Platform]]. The log's backlinks panel lists every decision, newest first, including superseded ones.

  3. Write the revisit line as @remind(2027-01-05 10:00). Scribelet sends a push reminder in your local time, so the review happens even if nobody remembers the decision.

  4. Next steps written as - [ ] Task (@Jonas) @due(2026-11-13) appear in the Tasks view and on your daily note until ticked.

  5. Ask the AI chat "why did we move the nightly jobs off cron?" and it answers from your decision notes with citations, which is faster than searching the log.

  6. On Pro, the stale checker flags notes that need review, a useful nudge for decisions whose context has moved on.

Templates, template variables and AI generation are documented in Note templates.

Frequently asked questions

What is a decision log?

A decision log is a running record of the significant decisions on a team or project: what was decided, when, by whom, which options were rejected, and why. Its job is to answer "why did we do that?" months later without relying on anyone's memory.

How do you document decisions made in a meeting?

During the meeting, mark the moment a decision is made. Afterwards, the keeper writes one log entry per decision: context, options, decision, reason, dissent and next steps, then links the entry from the meeting notes. Do it the same day, while the rejected options are still clear.

What is the difference between a decision log and a decision journal?

A decision log is usually shared and records team decisions so others can act on them. A decision journal is personal: it records your own choices along with your expectations, confidence and state of mind, so you can review later whether your judgment was sound. The fourth example above is a decision journal template in use.

Is a decision log the same as meeting minutes?

No. Minutes record what happened in one meeting, in order. A decision log pulls the decisions out of many meetings, emails and chats into one list that stays readable for years. If you need the formal record of a meeting, use the meeting minutes template.

How does a decision log relate to an architecture decision record?

An architecture decision record (ADR) is a decision log entry specialized for software design, usually stored next to the code. The fields overlap almost entirely. See these architecture decision record examples if your decisions are mostly technical.

How do I choose between options before logging the decision?

For a choice between several options with trade-offs, score them first with a decision matrix template, then log the winner with the matrix linked. For a broader method, see this decision making framework.

Stop deciding the same thing twice

Save this decision log template in Scribelet, put a revisit reminder on every entry, and ask your notes why a decision was made instead of reopening it. Encrypted, free to start.

Free plan, no credit card. See pricing

Guide

Note Taking App for Developers: Markdown, MCP and Notes Checked Against Your Code

Developer notes fail in a specific way: they are right on the day they are written and quietly wrong six months later. This page says which tool fits which developer, what belongs in the repo instead, and a setup where notes are Markdown, your coding agent can read and write them over MCP, and runbooks get checked against the actual code.

Planning

Decision Matrix Template

A weighted decision matrix scores each option against the criteria that matter, multiplied by how much each one matters. This template adds the two steps that make the total trustworthy: pass-or-fail must-haves before scoring, and a check of whether the winner survives a small change in weights. Copy it, or use the pros and cons version for a yes-or-no choice.

Meetings

Meeting Notes Template

One structure that captures the three things people come back for: what was decided, who owns what by when, and the context that made the decision make sense. Copy it as-is, or pick the example closest to your meeting.

Meetings

Meeting Minutes Template

Minutes are the official record: who was there, what was moved, how the vote went, and what was decided. Not a transcript. Copy the template, or start from the minutes example closest to your meeting, then read how approval works.

Engineering

RFC Template for Engineering Teams

An RFC (request for comments) is a short written proposal that asks reviewers to find the problems before the code does. This template adds what most RFC templates leave out: a named approver, a date comments close, and a Decision section, so the review ends instead of trailing off.

Article

Architecture decision record examples

From the Scribelet blog

We use cookies for analytics to improve your experience. Learn more