Ask a team what was decided in last Tuesday's meeting and you will usually get three answers. Nobody is lying. Each person heard the part that mattered to them, wrote down a line or two, and moved on to the next call. Two weeks later the difference between those three answers turns into rework, a tense email or a client who is sure they never approved the thing you built.
Decisions rarely get lost because people forget. They get lost because they were never put in one place to begin with. This post looks at where they go, why the usual fixes don't hold, and what a decision log changes.
Where decisions actually go
Think about a single decision on a real project: the launch moves from 28 April to 12 May. Here is where that decision lives a week later.
- In the call. It was said out loud at minute 12. Unless someone recorded the call and remembers roughly when, that is gone.
- In someone's notebook. The project lead wrote "launch → 12 May?" with a question mark, because at the time it was not clear whether the client had agreed or was thinking out loud.
- In a chat thread. The designer posted "so we're going with May?" and got a thumbs-up. Nobody can tell whether the thumbs-up meant yes or "I saw this".
- In an email. The account manager sent a follow-up that says "launch in May" without the date, because they were typing on a phone between meetings.
- Nowhere. The client's finance lead, who was not on the call, still has 28 April in their plan.
Each of those is a fragment. None of them is the decision. When someone asks "who agreed to this?", the team has to rebuild it from the fragments, and whoever has the most confident memory wins.
Why minutes don't fix it
Minutes feel like the answer. Somebody takes them, they get sent round, and they are filed. But minutes have three problems as a record of decisions.
They record the meeting, not the outcome. Good minutes say what was discussed. A decision is often a single line in the middle of a paragraph about something else, and the next person to read them has to work out which sentences are settled and which were ideas.
They are written late. Minutes are usually written up after the meeting, from memory and a few notes. The precise wording, the condition attached to it ("12 May, if the print proofs arrive by the 2nd"), the person who actually said yes: those fade first.
They live per meeting. To find a decision you need to know which meeting it was in. Decisions made in chat, in a hallway or on a site walk never get minutes at all.
None of this means minutes are useless. They are a good source. They are just not the record.
What a decision log is
A decision log is a running list of the decisions a team has made: what was decided, when, by whom, why, and where it was agreed. It is one list per project, not one per meeting. Our guide on what a decision log is covers the fields and the difference between a log, a register and a RAID log in detail. The short version is that four fields do most of the work:
| Field | Why it matters |
|---|---|
| The decision, in one sentence | Someone who missed the meeting understands it |
| Who decided | Settles "who agreed to this?" without a debate |
| When | Shows which decision is the latest when one replaces another |
| Where it was agreed | Lets anyone go back to the source and check |
The last field is the one most teams skip, and it is the one that ends arguments. "Client call, 7 October, about 12 minutes in" is something a person can go and check. "Agreed in a meeting" is not.
Why decision logs fail in practice
Plenty of teams have started a decision log and abandoned it within a month. The pattern is almost always the same.
- Someone sets up a spreadsheet with good columns.
- For two weeks they fill it in after each meeting.
- A busy week comes, the log falls behind, and catching up means reconstructing decisions from memory.
- People notice the log is out of date and stop trusting it, so they stop reading it, so nobody minds that it is out of date.
The problem is not the format. It is that writing the row is a separate job that happens after the conversation, done by one person, and that job is the first thing to go when the week gets busy.
Two habits help a lot. First, write the row in the meeting: read the decision back ("so we're agreeing the launch moves to 12 May?") and add it before moving on. Second, never delete a row. When a decision changes, add a new one and mark the old one as replaced, so the history stays readable. Our free decision log template has a status column for exactly that.
A log that fills itself in
The other fix is to stop making the log a separate job. That is the idea behind the decision log in Velkri.
A team talks on calls from the project, in video calls the notetaker joins from the calendar, and in WhatsApp groups imported into the project. Velkri picks out what sounds like a decision and shows it to the team as a proposal. The proposal says where it came from and when.
A person on the team then confirms it, edits it first, or dismisses it. That step matters. Software is good at noticing that something sounded like a decision; it is not the right judge of whether the client really agreed. The person who was on the call is. Only what someone confirms goes on the project's record.
Once confirmed, the decision appears on the project's timeline with who confirmed it, and in the project's decisions with a link back to where it was said. For a call, the link plays the recording from that point, so "about 12 minutes in" becomes a button.
Three things change once the log fills itself in:
- It is current. Rows appear while the work is happening, not at the end of the week.
- It covers more than meetings. Decisions from imported WhatsApp groups arrive the same way as decisions from calls.
- It ends arguments quickly. When someone remembers it differently, the answer is a link to the source, not a debate about whose memory is better.
You can also ask the project directly. "When did we move the launch?" gets an answer with a footnote that opens the call or message it came from.
Starting today, with or without software
If you take one thing from this post, make it this: a decision is not recorded until it has an owner, a date and a source. You can do that today with a spreadsheet.
- Open the decision log template or make a sheet with the four fields above.
- In your next meeting, read each decision back before moving on, and add the row on the spot.
- Put the link to the call recording, chat message or email in the "where" column.
- Once a week, spend five minutes checking the chat for decisions that were made there and never logged.
If the spreadsheet survives a month, you have a habit worth keeping. If it doesn't, that is usually because filling it in is a job nobody has time for, and that is the job Velkri takes off your hands.