Meeting Decision Log Template: Write Down What You Rejected, Not Just What You Chose

The short answer

One entry per decision, five lines: what was decided, what was rejected, why, who decided, and what would reopen it.
The rejected options are the point. The winner is usually obvious from the work itself. The losers vanish the moment the meeting ends.
"Revisit if" is the field that makes it work. It turns "can we talk about this again?" from a relitigation into a check: has the condition happened, yes or no.
One running log, newest on top, not a decisions section buried in every meeting's notes.
Say the rejection out loud before you move on. "So we're not doing B, because X." Ten seconds. Your recording can't catch a sentence nobody said.
Steal the template below, or paste the prompt version into your notetaker.

Full disclosure: I make Humla, a meeting notetaker, and yes, it appears later in this post, with its limits. But like the action items post this is a sibling of, most of what follows works with a text file and a bit of discipline.

The Zombie

Every team I've ever worked in has one. You probably do too.

It's the argument that was settled. Properly settled - everyone was there, it took forty minutes, there was a whiteboard. And then, somewhere around week six, someone new joins the project, or someone who was on holiday that day comes back, or someone who WAS there just can't remember why, and they say the fatal words: "Out of curiosity, why didn't we just go with..."

And it's back. Shambling out of the ground. Same arguments, same forty minutes, sometimes the same whiteboard. Occasionally a different answer, which is the truly unsettling part, because nothing actually changed except who happened to be in the room.

I've started calling this the Zombie, partly because it's accurate and partly because it helps me take it less personally when it happens. (It happens to me a lot. I am frequently the person who can't remember why.)

Here's what took me an embarrassingly long time to notice: the Zombie almost never comes back because the decision was wrong. It comes back because the REASONS died, and the decision was left standing there on its own like a signpost with the arrow painted off.

What a summary gets and what it drops

Our agency has meetings every day - client scoping, design reviews, the internal "okay, so what are we actually doing" ones. I read a lot of the transcripts afterwards, because building a notetaker makes you that kind of person.

And when I went looking for decisions in them, a pattern showed up that I didn't expect.

The winning option is almost always in there, loudly. People say it, repeat it, agree to it. Any decent summary catches "we're going with the headless setup" because the room said it four times.

The losing options are in there too, sort of. Spread out, half-discussed, mixed in with everything else. But the moment where one of them actually DIED? That usually wasn't a sentence. Nobody said "we're rejecting the plugin approach because it locks us into their update schedule." What happened was that somebody raised the update-schedule thing, a few people made that face, and the conversation just... stopped going there. The rejection happened in the silence between two topics.

Which means the most valuable sentence in the whole decision - the reason B lost - quite often exists only as a feeling four people had at 14:20 on a Tuesday. You can't transcribe a feeling. (I've checked. Believe me, I've checked.)

That's the whole argument for a decision log that's more than a list of conclusions. The conclusion survives without help. The reasoning needs someone to write it down on purpose.

The five fields

Field	What goes in it	Why it earns its place
Decided	The choice, in the terms it was made in	The part everyone remembers anyway
Rejected	Each alternative that was seriously on the table	Stops someone "discovering" it again in six weeks
Why	The reason the winner won, or the loser lost - one line each	This is what actually kills the Zombie
Decided by	The name of whoever made the call, and who was there	So "who agreed to this?" has an answer that isn't a shrug
Revisit if	The specific condition that would make it worth reopening	Turns relitigation into a yes/no check

A couple of these deserve more than a table cell.

"Rejected" only means seriously considered. Not every idea anyone floated. If you list twelve alternatives including "what if we just didn't," nobody reads the entry. Two or three, the ones someone would plausibly suggest again. That's your test, actually: would a reasonable new person propose this? Then it goes in.

"Why" should be the real reason, even when it's unflattering. "Cheaper" is a real reason. "Kari has built three of these and nobody else has built one" is a real reason. "The client's IT guy hates it and we didn't want the fight" is a completely real reason that people are weirdly reluctant to write down, and it's exactly the one that matters when the IT guy leaves. Write the reason that was actually decisive, not the one that sounds best in a document.

"Revisit if" is the one I'd keep if I could only keep one. Without it, every "can we reconsider?" is a judgment call about whether the asker is being difficult. With it, it's a lookup. "We picked the managed host. Revisit if monthly traffic triples or they drop the EU region." Somebody wants to reopen it? Cool. Has traffic tripled? No? Then it's not reopened, and nobody has to be the bad guy about it. And if it HAS tripled, reopening it is the plan working, not somebody being awkward.

That last bit is the part people miss. A good decision log doesn't make decisions permanent. It makes them reopenable on purpose, which is the opposite of reopenable by accident.

One log, not one per meeting

In the action items post I put a Decisions section at the top of each meeting's notes, and I still think that's right for the notes. But a decision log is a different object.

Meeting notes are organised by when you talked. Decisions are needed by what they're about. When somebody asks "why is the staging site on a different host?", nobody knows which of forty meetings to open. So the log is one file (per project, per client, per team - whatever your natural unit is), newest entry on top, and each entry points back to the meeting it came from.

Two rules for the file itself:

Never edit an old entry to change the decision. If it gets reversed, write a new entry that says so and points at the old one. The old one stays, marked superseded. This feels fussy right up until the day you need to know what you believed in March and why, and then it's the most useful thing you own.

Decisions made outside meetings go in too. The Slack thread at 11pm, the hallway "yeah fine let's do that". Those are the Zombie's favourite breeding ground, because there's no meeting note to even look in.

The template

Plain Markdown on purpose, so it survives being pasted into Obsidian, Notion, a repo, a shared doc, wherever. (Software people will recognise this as a lightweight cousin of the architecture decision record. Everyone else: it's just a list with good manners.)

# Decision log - <project or client>

<!-- Newest first. Never edit a decision; supersede it. -->

## 2026-09-29 - <short name of the decision>
**Decided:** <the choice, in the words it was made in>
**Rejected:**
- <option B> - <why it lost, one line>
- <option C> - <why it lost, one line>
**Why:** <what actually tipped it, even if it's unglamorous>
**Decided by:** <name> (with <who was there>)
**Revisit if:** <specific, checkable condition> | none - this is settled
**Source:** <meeting name + date, or "Slack thread", or "hallway">
**Status:** active

## 2026-08-14 - <an older decision>
...
**Status:** superseded by 2026-09-29 - <short name>

Some small things that matter:

The heading is date + name, so the file reads as a timeline when you scroll and a list when you search.
"none - this is settled" is a legitimate value for Revisit if. Some decisions really are done. Saying so out loud is useful too.
"Decided by" is one name. Same rule as owners on action items: groups don't make decisions, people do, and a group "decision" that nobody will put their name to is usually a mood rather than a decision. (Somebody Else, from the action items post, would love to be listed here. Don't let him.)
Status is a word, not a checkbox. active, superseded, reversed. There's nothing to tick off - a decision isn't a task.

The ten-second move

Same trick as with action items, and it's even cheaper here.

When a decision lands in a meeting, say the rejection out loud before moving on:

"Okay, so managed hosting. We're not doing the VPS because nobody wants to be on call for it, and we're not doing their shared plan because of the EU thing. If traffic triples we look at it again. Next thing."

That's the whole entry, spoken. Every field is in there. And it does something the written version can't: it gives anyone who disagrees one last clean moment to say "wait, that's not why." Surprisingly often, someone does. Better that happens at 14:21 than in week six.

It also hands your recording the one sentence it needed. Which brings us to the robot bit.

Okay, the AI part

If you record meetings, you can get a first draft of this log without typing it. How good that draft is depends almost entirely on the ten-second move above.

What extraction genuinely gives you: the decisions themselves, reliably, and the options that were discussed. For the "Decided" and "Rejected" fields, a transcript is a better memory than mine. It also catches the decision that got made while you were typing something else, which is exactly the one you'd have forgotten to log.

What it can't give you: a reason nobody said. If B died in a silence, there's nothing to extract. A tool that gives you a crisp "rejected because..." for an option nobody explicitly rejected is guessing, and a guessed reason is WORSE than a blank one. A blank says "go ask Kari." A plausible fake reason sends the Zombie back into the ground with the wrong tombstone on it, and it'll come back angrier.

So the instruction that matters in any prompt you write is: don't infer the reason. Here's a custom prompt that produces the log format. In Humla it goes in Settings → Summary → "Your prompts", and you pick it per note from the preset dropdown in the Summary panel, then regenerate. Custom prompts run literally, so what you write here is what the model gets.

You extract decisions from [Notater] (user-written) and [Transkripsjon] (auto).

For each decision that was actually settled in this meeting, write one entry:

## <short name of the decision>
**Decided:** the choice, in the words used in the meeting.
**Rejected:** each alternative that was seriously discussed, with the reason it
lost ONLY if that reason was stated. If no reason was stated, write
"reason not stated".
**Decided by:** the person who made the call, if that is clear. Otherwise write
"not stated".
**Revisit if:** a condition only if one was said out loud. Otherwise write
"not stated".

Never infer a reason, an owner, or a condition. "Not stated" is a correct answer.
If nothing was decided, reply with exactly: No decisions.

Reply in English using Markdown.

([Notater] and [Transkripsjon] are the literal labels Humla puts on your typed notes and the transcript when it sends them to the model. They're Norwegian because I am. If you're using this with a different tool, swap in whatever it calls those two inputs.)

Look at what that prompt produces for a normal meeting and you'll see a lot of "reason not stated." That's not the prompt failing. That's an accurate picture of what got said, and every one of those is a gap you can fill in the next thirty seconds while you still remember. Which is, honestly, the best use of the whole thing: not writing the log for you, but pointing at exactly where your memory needs to do the work.

There are two lighter-weight routes in Humla's chat too, if a custom prompt feels like commitment. Type / in a note's chat and one of the canned prompts is "Key decisions" - what that one meeting settled. And in the library-wide chat there's one called "Decisions log", which asks what was decided recently and where, and answers with the meetings cited. That second one is the useful one for backfilling: if you're starting a log for a project that already has three months of history, it's a much faster first pass than reopening every note. Treat its answer as a list of candidates to check, not as the log itself - for the same reason as above, it can only find what was said. (More on how that cross-meeting retrieval works in chat with your meeting history.)

And the honest limit on my side: Humla doesn't write to your log for you. There's no "append to Notion" button. What it has is a read-only MCP server, so an AI agent you already use can read your notes and do the appending on its side. If you want decisions flowing into a wiki automatically with zero setup, a cloud tool with that integration built in will get you there faster than mine will.

Things that look helpful and aren't

Logging every choice. Which font for the internal deck is not a decision-log decision. The test is the Zombie test: is there a realistic chance someone argues about this again? If not, it lives in the meeting notes and nowhere else.

Logging the discussion instead of the decision. "We talked a lot about hosting, there were concerns on both sides" is a meeting note wearing a decision log's clothes. If you can't fill in "Decided:", nothing was decided, and that's an open question - which is a real and useful thing to write down, just somewhere else.

Making it someone's job to maintain. The moment one person owns the log, it becomes a thing they do on Fridays when they remember, and everyone else stops reading it because it's not theirs. Whoever made the call writes the entry. Five lines. Straight after the meeting, while the reason is still warm.

Anyway. Next time someone asks why you didn't just go with the obvious thing, you'll have the answer in a file instead of a forty-minute meeting. And the Zombie can stay in the ground where it belongs. Mostly. It's a zombie.