Build a decision log that stays useful across meetings

Decide what belongs in the log

Pick a scope people can search and keep up to date, such as one project or one planning group. Log decisions that change a direction, constraint, owner or commitment. Task updates belong on the work board. Brainstormed options stay proposals until someone with authority chooses.

Name someone to maintain the log and agree where it lives. A shared document or table is enough to start. Don't rely on one person remembering which meeting had the final answer.

Give every decision a stable ID

Number each entry so later notes point to the same record instead of creating competing versions. Michael Nygard's widely used format for architecture decision records numbers them in sequence and never reuses a number.

During a meeting: confirm before you log

Read the proposed decision back to the decision maker. Check its scope, conditions and any disagreement that affects delivery. Log anything unresolved as pending, with an owner for the missing input. A strong recommendation is not an approval.

If authority is unclear, a framework like DACI helps; our answer on decision-making meetings explains its roles. Whatever you use, every entry needs a named decision maker. Atlassian's DACI play says the same: once a decision is made, document it so future teams can see how and why.

An example entry

In this fictional example, a workshop team decides where to store participant materials. Keep the reasoning short enough to scan, and link detailed evidence separately. The review trigger matters because a sound choice can go stale when its assumptions change.

After the meeting: make the current choice easy to find

Link the entry from the related task, project brief or follow-up message. Tell affected people what changed and what they need to do. The log records the choice. Your work system still tracks whether the actions happened.

If you record meetings in Bridge, each meeting's notes include a decisions section next to the summary and follow-ups. Treat it as a draft to confirm with the decision maker before you add a log entry.

When someone wants to reopen a choice, capture the new information and take it to the decision maker. If it changes, mark the old entry superseded and link the new one. Keep the old reasoning and date. Nygard's format handles reversals the same way.

Review conditions, not every past discussion

At each milestone, check active decisions whose review triggers have fired. In the workshop example, a failed guest-access test calls for review; a preference for a different folder name probably doesn't. Archive decisions that no longer apply, with a note explaining why.

A log can't create authority the team hasn't assigned, or settle a dispute just because a row exists. Keep sensitive details behind the right access controls. Start small. A huge log nobody updates will mislead its readers.