Aren't meeting minutes enough to track decisions?

No. Minutes record the discussion, and decisions drown in them. A reader six weeks later has to reconstruct what was actually agreed from a narrative of who said what. Track decisions as their own artifact: verdict, reason, owner, date. Keep minutes too if you like; just don't make anyone mine them for verdicts.

What if the meeting ends without a clear decision?

Then record that, explicitly: what's still open, who decides, and by when. The most expensive outcome is ambient agreement: five people leaving with four different memories of what was decided. 'No decision yet, Priya decides by Friday' is a perfectly good entry.

Who should record the decision: a note-taker or the decider?

The decider, or the meeting owner on their behalf. A dedicated note-taker transcribes; they can't always tell a verdict from a strong opinion. The person who owns the call is the only one who can state it precisely, and asking them to say it in one sentence is itself a useful forcing function.

How do you track decisions made in meetings?

Capture in the meeting, not after. Name the decider before discussion starts, state the verdict as one sentence when it lands, record it with the reason and owner in the last two minutes, and send it to everyone affected the same day. Minutes written afterwards are archaeology, not tracking.

Most meetings don't fail to make decisions. They fail to notice they've made them. A discussion converges, heads nod, the agenda moves on, and five people leave with four different memories of what was agreed. Tracking starts with making the decision itself visible, in the room, before anyone tries to write it down.

Why meeting decisions evaporate

Meetings produce ambient agreement, not explicit verdicts. Consensus arrives as a feeling (the pushback stops, someone says "okay, so we're aligned"), and a feeling can't be filed. Unless someone converts it into a sentence on the spot, each attendee saves their own version, and the versions diverge the moment they hit separate inboxes.

The traditional answer, minutes-after-the-fact, fails structurally: written hours later from fading memory, they blend decisions into a narrative of discussion, and they're stored where nobody looks. And ambiguity about who decides makes it worse. Paul Rogers and Marcia Blenko's Harvard Business Review classic "Who Has the D?" found that the biggest drag on organizational decision-making is exactly this: nobody being sure who holds the decision. A meeting where the decider is ambiguous can't produce a trackable verdict, because there's no one whose sentence counts as final.

What actually works

Name the decider before the discussion starts. One person, stated in the agenda. Bain's RAPID framework formalizes this if you want the full apparatus (or DACI, its lighter cousin, compared in our DACI template), but the minimum dose is a single line: "Priya has the D on this one." Everything downstream depends on it.

State the verdict as one sentence, in the room. When the call lands, the decider says it plainly: "Decision: we move the launch to May 4th." If it can't be said in one sentence, it's several decisions, or not yet a decision.

Close with a two-minute sweep. Before ending, the meeting owner reads out every decision made: verdict, reason in a clause, owner, and a review date if the call is temporary. This is where the four different memories get reconciled, while everyone who holds one is still present. It's the cheapest correction window that will ever exist.

Separate decisions from action items. "Ship the beta May 4th" is a decision; "Sam updates the launch doc" is a task. Task trackers eat decisions and never give them back. Keep a decision register: one running, append-only list per team, each entry dated and owned. Which fields it needs, and which tools can hold them, is in what a decision register should store.

Distribute the same day. A decision that reaches only attendees isn't tracked; it's gossip with a timestamp. Send the register entries to everyone whose work they touch, and link, never re-paraphrase, when the decision comes up later. Reversals get a new entry pointing at the old one, so the record keeps its history.

The fields that make an entry worth reading later (the reason and the rejected alternatives) are the same ones engineering teams use in decision logs (here's which decision log tools fit which teams), and skipping them has the same failure mode: verdicts that can be obeyed but never re-evaluated.

What does a meeting decision entry look like?

The two-minute sweep should produce entries that someone who wasn't in the room can act on. For a launch-planning meeting, one entry might read:

Decision:  Move the public launch from April 20 to May 4.
Reason:    Payments integration needs a second round of QA; the partner
           webinar can move, the integration can't ship half-tested.
Rejected:  Launch April 20 without annual plans (support load, confusing
           pricing page).
Decider:   Priya (Head of Product)
Agreed:    Sam (Eng), Lee (Marketing)
Review:    None, unless QA finds a blocker by April 27.
Tasks:     LAUNCH-112 update launch doc; LAUNCH-113 reschedule webinar

Note that the tasks are links, not the entry itself: the decision outlives the tickets. A ready-to-copy version of this format is in our decision log template.

Does every decision need a meeting?

No, and most shouldn't have one. Reversible, low-stakes calls move faster in writing, with a proposal, a named decider, and a deadline. Meetings earn their cost for the contentious or irreversible ones. The written path is laid out in how async decision-making works in distributed teams; calls that land in Slack threads have their own failure modes, covered in how to stop product decisions getting lost in Slack.

If your team ships software, Lockstep applies this discipline automatically to product and engineering decisions: it captures them from Slack, Notion, Jira, Confluence, Google Docs, and GitHub PRs, and the owner approves each one in a click. See how it works.