The Common Table Notes
Shared Decisions

How to Make a Simple Team Decision Log

The Common Table Notes · Updated 2026-07-19 · 4 min read
How to Make a Simple Team Decision Log
In briefCreate a team decision log with one row per choice and fields for ID, date, decision, owner or authorized body, reason, constraints or objections, and review trigger. Separate decisions from actions, proposals, and questions. Write each choice as a scoped sentence, preserve uncertainty and disagreement accurately, link supporting records, and mark later changes as new decisions rather than silently editing history. Keep the log in one controlled location, avoid sensitive personal details, and assign a maintainer plus backup.
Contents

Record the choice, not the entire meeting

Make a simple team decision log with one row per decision and seven fields: ID, date, decision, owner, reason, constraints or objections, and review trigger. Link supporting documents rather than pasting the whole discussion. Keep the log in one agreed location, restrict sensitive information, and read new entries back to the people affected.

The goal is not surveillance or perfect minutes. It is to answer, three months later, “What did we choose, who could choose it, and what would make us revisit it?” without convening an archaeological panel.

Use seven practical columns

Create a table with:

Field What to record
ID A short stable label, such as D-014
Date When the decision became active
Decision One complete sentence stating the choice
Owner Person or authorized body responsible for it
Reason The main evidence, goal, or tradeoff
Constraints or objections Limits, minority concerns, or conditions
Review trigger Date, event, evidence, or threshold for reconsideration

Optional fields include status, project area, affected people, supporting link, and superseded decision ID. Add a field only when someone will maintain and use it. Every extra column begins life looking helpful and ends by demanding a dropdown nobody understands.

Distinguish a decision from an action

A decision selects a direction: “Use the library meeting room for the pilot.” An action moves it: “Mara will submit the room request by Friday.” Store actions in the task system with owners and due dates, then link them to the decision if helpful.

Also separate proposals, questions, and assumptions. A discussion point does not become policy because it appeared in meeting notes. Mark status clearly:

The guide to running a volunteer project kickoff shows where the log fits into a first meeting.

Write the decision as a testable sentence

Begin with an active verb and include scope. “Communications” says nothing. “Publish one weekly project update on the public website through the end of the pilot” states what, where, how often, and for how long.

Avoid rewriting uncertainty out of the record. If a temporary choice was made because information was missing, say so and name the review trigger. If a qualified authority must approve it, label the decision conditional. If people disagreed, capture the concern in neutral language and record whether it remains unresolved.

More lightweight governance methods live in Shared Decisions.

The owner is not necessarily the loudest participant or the person typing. Name the person, committee, board, property owner, funder, partner, or other body with actual authority. If the group only recommends, write “recommend” rather than “decide.”

For choices affecting personal data, safeguarding, access, money, legal duties, safety, or protected rights, use the responsible organization's required process and qualified advice. A decision log documents authority; it does not create authority that never existed.

Do not list sensitive personal information, confidential allegations, medical details, access needs, or private contact data in a broadly shared log. Use minimum necessary detail and link to an appropriately restricted record when a lawful and legitimate need exists.

Make review triggers meaningful

A review trigger explains when the choice deserves another look. Examples:

Not every decision needs an expiry date. Some remain valid until superseded. Still, avoid “review later,” which is a calendar event scheduled in the ancient land of Neverember.

When a decision changes, preserve the old row and mark it superseded. Add the new decision with its own reason and link between them. Silent editing destroys the history the log exists to protect.

Keep ownership of the log simple

Assign one maintainer and at least one backup. Define who may view, propose, approve, and edit. Use version history where available, protect credentials, and export a backup on a sensible schedule. Review access when volunteers or staff leave.

At each meeting, scan new and triggered decisions rather than reading the entire ledger aloud. Confirm corrections promptly. Invite affected people to question an entry through a clear route, especially when they were absent.

Test the log with three questions

Pick a recent decision and ask:

  1. Can a new volunteer understand the choice without oral folklore?
  2. Can they see who had authority and why the tradeoff was made?
  3. Can they tell what would cause review?

If yes, the log is doing enough. Resist turning it into a complete institutional memory, task manager, risk register, minutes archive, and feelings journal. Small systems survive when their job stays small—and when somebody besides the person who invented the color coding can operate them.

FAQ

What belongs in a decision log?

Include choices that set direction, commit resources, define scope, accept a tradeoff, establish a rule, or affect other people. Record the choice, authority, reason, important constraints or objections, and review trigger. Routine task updates belong elsewhere. A decision log should be concise enough to scan while still explaining why the team did not choose an obvious alternative.

Who should own the decision log?

Assign one maintainer and at least one backup, with clear permissions for viewing, proposing, approving, and editing. The maintainer records decisions but does not automatically gain authority to make them. Review access when people join or leave, protect credentials, use version history, and keep backups appropriate to the project's sensitivity and retention requirements.

Should disagreements appear in a decision log?

Yes, when they materially affect the choice, risk, implementation, or future review. Summarize the concern neutrally and accurately rather than naming people unnecessarily or replaying the entire debate. State how the decision rule handled it and whether it remains unresolved. Keep confidential or sensitive detail in an appropriately restricted process, not a broadly shared row.

How do I change a decision already in the log?

Keep the original entry, mark it superseded or withdrawn, and add a new row stating the revised decision, authority, reason, date, and review trigger. Link the two IDs. Do not silently replace old wording, because the previous choice may explain completed work, spending, or communication. Correct genuine recording errors transparently through the agreed process.

Is a decision log the same as meeting minutes?

No. Minutes can record attendance, discussion, reports, actions, and procedural details for one meeting. A decision log extracts choices across many meetings and channels into a durable, searchable record. Link to minutes for supporting context when needed. Keeping the functions separate prevents the log from becoming an unreadable transcript and helps newcomers find current decisions quickly.