What Is a Decision Log? (And Why Most Teams Still Don’t Have One)
A decision log records what your team actually decided — not just what was discussed. Learn what belongs in one, how it differs from meeting notes, and how to keep one without the admin.
A decision log is a running record of the decisions a team has made — what was decided, who decided it, why, when, and what happens next. It is different from meeting notes, which capture what was discussed, and from transcripts, which capture what was said. A decision log captures what was settled.
Why "we agreed on this" turns into an argument
I spent years as a clinical psychologist and ran more than 10,000 sessions. When I moved into the working world, I expected the conflicts to be different. They weren't. The most common one I hear from managers is still some version of:
That's not what we agreed.
Here's the part people find surprising. In most of those disputes, both people are telling the truth as they remember it. Human memory isn't a recording. It's a reconstruction — assembled fresh each time, and quietly shaped by what you wanted, what you expected, and what happened afterwards. Two people leave the same forty-minute meeting holding two different versions of the outcome, and neither of them is lying.
This is why the fix isn't "pay better attention." It's a record. A specific kind of record.
If you can't write the decision in one sentence, it wasn't a decision. It was a discussion.
What is a decision log, exactly?
A decision log is a single, continuously updated list of every meaningful decision a team, project or partnership has made. Each entry is short — usually two or three lines. The log answers one question, permanently: what did we decide, and why?
It is sometimes called a decision record, a decision register, or an ADR (architecture decision record) in software teams. The name changes. The job doesn't.
A decision log is deliberately narrow. It does not hold the debate, the tangents, the status update or the small talk. It holds the outcome. That narrowness is the entire point — a log you can scan in ninety seconds gets used, and a log that gets used is the only kind that works.
Decision log vs meeting notes vs transcripts: what's the difference?
These three artefacts get treated as interchangeable. They aren't. Each answers a different question, and each fails at the others.
| Transcript | Meeting notes | Decision log | |
|---|---|---|---|
| Captures | Every word said | What was discussed | What was settled |
| Answers | "What were the exact words?" | "What did we cover?" | "What did we agree, and why?" |
| Length | 8,000+ words per meeting | 200–600 words | 2–3 lines per decision |
| Spans | One meeting | One meeting | Every meeting, indefinitely |
| Best for | Disputes, compliance, exact quotes | Catching up if you missed it | Alignment, onboarding, revisiting past calls |
| Fails because | Nobody re-reads 8,000 words | Discussion and decision blur together | Requires discipline to maintain |
The critical difference is the last row but one: scope. Notes and transcripts are per-meeting artefacts. They live in the meeting they came from. A decision log is a continuous thread that runs across every meeting, so you can trace how a project's thinking actually evolved — not dig through eleven separate documents hoping the answer is in one of them.
A transcript is not a decision log. This trips up a lot of teams who've adopted AI notetakers. Having the full text of a conversation feels like having the record. But nobody re-reads a transcript, and searching one gives you the moment a topic was raised just as readily as the moment it was resolved. Raw capture isn't the same as a usable record.
What does a good decision log include?
Seven elements. Miss the third one and the log becomes far less useful in six months' time.
| Element | The question it answers | Why it matters |
|---|---|---|
| The decision | What was actually settled? | One sentence. If it takes a paragraph, it's not settled yet. |
| The date | When was this decided? | Lets you sequence decisions and spot when a call was superseded. |
| Who decided | Whose call was it? | Removes the "I thought you were deciding" failure mode entirely. |
| Who was party to it | Who was in the room? | Tells you who to loop in when it's revisited — and who genuinely wasn't there. |
| The rationale | Why this, and what did we rule out? | The most-skipped and most valuable field. Without it, you re-litigate the same debate in three months because nobody remembers why the obvious alternative was rejected. |
| Next steps | What happens now, and who owns it? | Connects the decision to action. A decision with no owner is a preference. |
| Status | Is this still live? | Decisions get superseded. A log that can't show that becomes misleading. |
The rationale field is the one to fight for. Teams that log what they decided stop repeating decisions. Teams that log why stop repeating arguments.
When do you actually need a decision log?
Not every meeting needs one. These situations do.
Co-founder and leadership conversations. High stakes, no minute-taker, and the two people involved are the two people with the strongest and most divergent views. This is where "that's not what we agreed" does the most damage, because it isn't a process failure — it reads as a trust failure.
Project kickoffs and long-running projects. Scope decisions made in week one get quietly reinterpreted by week nine. A log makes drift visible while it's still cheap to correct.
Client, agency and vendor relationships. The commercial reason is obvious. The relational one matters more: a shared record means neither side has to be the one who "remembers differently," which is a conversation that damages working relationships even when you win it.
Performance and development conversations. If you agreed a plan with someone in March, both of you need the same version of it in June. Vague performance agreements are one of the most reliable ways to erode trust with a direct report — they feel like moving goalposts even when nobody moved anything.
Distributed and asynchronous teams. People who weren't in the room need to know the outcome without watching a recording or asking someone to summarise it.
Anything you'll be asked to justify later. Regulatory, board-level, safety, or budget decisions. The rationale field is what saves you.
The part most teams get wrong: it's not a documentation problem
Here's the reframe I'd push hardest.
Most people treat a decision log as an admin task — filing, hygiene, something the organised person does. That framing is why they abandon it by week three. Admin tasks always lose to real work.
A decision log is not a filing system. It's an alignment instrument.
The value isn't created when you read the log back. It's created in the ten seconds it takes to write the entry. Because the act of writing one clear sentence forces a question that meetings are extraordinarily good at avoiding: do we actually agree, or did we just stop talking about it?
Meetings end for all sorts of reasons that aren't agreement. Time runs out. Someone senior says something with enough conviction that nobody pushes back. Two people use the same word to mean different things and never discover it. Everyone nods, and nodding gets recorded as consensus.
Ambiguity is comfortable in the room and expensive outside it. Writing the decision down is what makes ambiguity surface while the people who could resolve it are still on the call.
From the practice. In coaching, the moment that changes a session is rarely new information. It's precision. When someone is forced to state a vague thing exactly, they usually discover they didn't believe it. Decision logs do the same thing to teams. The sentence is the intervention.
Why most teams try and fail to keep one manually
Almost every team I've worked with has attempted this. Most attempts die the same way.
Someone has to remember, in the moment. During a difficult conversation, your working memory is fully occupied managing the conversation. Documentation is the first thing to go — and the harder the conversation, the more likely it is you'll need the record.
The note-taker is rarely the decision-maker. So the log gets written by whoever had the least to contribute, filtered through their understanding of a discussion they were only half following.
Or worse, it's written by the person with the strongest view. Then the log quietly records what they wanted to be decided. Nobody's acting in bad faith. It just happens.
It lives somewhere nobody looks. A Notion page, a pinned Slack message, a tab in a spreadsheet. It's accurate for a month and stale forever after.
Decisions get split across a dozen meetings. The one you need was made in a Tuesday standup four months ago. You know it happened. You cannot find it.
The pattern is consistent: the discipline required is highest exactly when capacity is lowest. That's not a willpower problem. It's a design problem.
How Evro builds your decision log automatically
This is the problem we built Evro to remove — and I'll be specific about how it works, and where the limits are.
Evro is an AI meeting assistant that records and transcribes your meetings, or imports transcripts you've recorded elsewhere in Zoom, Teams or Google Meet. It runs privately alongside your meeting software rather than joining as a visible participant, though you can announce that you're recording — and you should. Every use case we design for assumes participants know a recording is being made.
Where Evro differs from a notetaker is what it does with the transcript.
It separates decisions from actions. Most tools produce one undifferentiated list of "key points" and leave you to sort it. Evro treats these as structurally different things:
- A decision is recorded when two or more people reach alignment on a topic and the reasoning behind it is identifiable in the conversation. The rationale — the field manual logs almost always skip — comes from the discussion itself, because it's already there in what people said.
- An action is a task-level commitment: one person agreeing to do something. It may sit under a decision, but it doesn't need a rationale of its own.
It rolls them up across every meeting. This is the part that makes it a log rather than another per-meeting summary. Evro gives you two views:
| View | What it shows | Use it when |
|---|---|---|
| Global view | Every decision and action you've been party to, across every meeting you've recorded or imported | You know something was decided. You don't remember where. |
| Folder view | The same, filtered to one project, client, agency or person | You're preparing for a specific conversation, or onboarding someone into a project's history |
It lets you ask questions of a project's history. Group your meetings into a folder and you can chat with an assistant that reads only that folder's transcripts — not the internet, not your whole account. "What did we decide about the pricing tier?" returns an answer grounded in the actual conversations, with the context around it.
Actions go where you already work. Copy them into your task manager, or use Evro's built-in task tracking with due dates and priorities.
It's yours alone. Your recordings, analysis and coaching are visible only to you. Evro doesn't report to your manager, your team or your employer. That's how the product is built, not a setting you have to find.
One honest note. AI summarisation is strong but it isn't infallible, and Evro is currently in beta. Treat the log as a draft that's 95% written for you rather than an infallible record — scan it after a significant meeting, and correct the occasional entry that landed slightly off. That's still a fundamentally different task from writing it from scratch while trying to hold a difficult conversation.
Curious what your last month of meetings would look like as a decision log? Import an existing transcript and see the output before recording anything new.
Stop reconstructing what you agreed.
Evro turns your real meetings into a decision log you can actually search.
Get started with Evro
A worked example
Here's the same meeting captured three ways.
The situation. A 45-minute product planning call. Four people. The team debates whether to ship a smaller version of a feature in Q3 or the full version in Q4. Priya argues for Q3. Tom raises a support-load risk. They land on Q3, scoped down, with a check-in before launch.
| Artefact | What you have three months later |
|---|---|
| Transcript | 9,400 words. The answer is in there, somewhere around minute 31. |
| Meeting notes | "Discussed Q3 vs Q4 timing for the feature. Team raised support concerns. Priya to follow up." Did they decide? Unclear. |
| Decision log entry | Decision: Ship the reduced-scope version in Q3, not the full version in Q4. Decided by: Priya (Product). Present: Priya, Tom, Alex, Sam. Date: 14 May. Rationale: Earlier user feedback outweighs feature completeness; full scope deferred to Q4. Support-load risk raised by Tom, accepted with a pre-launch check-in. Next: Alex to scope the reduced version by 21 May. Support review two weeks before launch. Status: Live. |
When someone asks in August why the full version wasn't shipped, the third row answers it in one read. The other two start a conversation.
How to start a decision log this week
You don't need a tool to begin. You need a habit and a home.
- Pick one place. One document. Not a doc per project — a single running log per team, newest at the top. Fragmentation is what kills these.
- Reserve the last two minutes of the meeting. Ask out loud: "So what did we decide?" Say it back. Watch how often that question produces a correction. That's the log paying for itself before anything is written down.
- Write one sentence plus the reason. Skip the fields you don't need. Never skip the reason.
- Review it at the start of the next meeting. Thirty seconds. This is the step everyone drops, and it's the one that keeps the log alive.
Do that for three weeks and you'll know whether the habit will survive contact with a busy month. In my experience, it survives for the first project and then quietly stops.
Which is the honest argument for automating it. The discipline isn't hard because people are careless — it's hard because it demands attention precisely when you have none left. Removing the requirement to remember is the only version that lasts.
Stop reconstructing what you agreed.
Evro turns your real meetings into a decision log you can actually search.
Get started with Evro
Frequently asked questions
What is a decision log?
A decision log is a running record of the decisions a team has made, capturing what was decided, who decided it, why, when, and what happens next. It differs from meeting notes, which record what was discussed, and from transcripts, which record what was said.
What's the difference between a decision log and meeting notes?
Meeting notes capture the full content of a single meeting — discussion, updates and decisions mixed together. A decision log captures only outcomes, and runs continuously across every meeting. Notes tell you what happened in one session; a log tells you what your team has committed to over time.
Is a decision log the same as a decision register or an ADR?
Effectively, yes. "Decision register" is common in project management and governance. "ADR" (architecture decision record) is the software-engineering version, usually one file per decision with a fixed template. Both are decision logs with different naming conventions.
What should a decision log entry contain?
Seven elements: the decision in one sentence, the date, who made the call, who was present, the rationale including rejected alternatives, the next steps and their owner, and the current status. The rationale is the most frequently skipped and the most valuable — it's what stops teams re-litigating settled arguments.
Who should maintain the decision log?
Traditionally the meeting owner or project lead, because they have enough context to distinguish a decision from a discussion. In practice this fails often, since that person is usually the one running the conversation. Automating capture removes the dependency on any one person's attention.
Do small teams need a decision log?
Small teams need one more than large teams, not less. Large organisations have governance processes that force decisions into writing. A two-person founding team has nothing but memory — which is exactly where "that's not what we agreed" does the most damage.
Can AI create a decision log automatically?
Yes. AI meeting tools can extract decisions from a transcript and organise them into a running record. The important distinction is whether the tool separates decisions from general discussion and rolls them up across meetings, or just produces a per-meeting summary. A summary per meeting isn't a log. Evro separates decisions from actions and rolls both up across every meeting you've recorded or imported.
How is a decision log different from an action item list?
An action item is a task one person commits to. A decision is an alignment two or more people reach on a direction. Actions tell you what's being done this week; decisions tell you why. Teams that track only actions end up executing efficiently on choices nobody can explain.
Curious what your last month of meetings would look like as a decision log? Practice the hard conversation first, or see how it fits your pricing needs on our pricing page.
About the author
Dr Jay Spence is Co-Founder and Co-CEO of Evro. A clinical psychologist by training, he has delivered over 10,000 clinical and coaching sessions and has spent his career studying why people who genuinely want to understand each other so often don't. He built Evro to move communication support out of the therapy room and into the meeting.