ConsultantStack

Delivery artefacts · 2026-10-25

The Meeting Notes Are Not the Work. The Decision Log Is.

An hour-long client call produces a transcript, a page of notes, and a set of action items. Two days later the notes are unread, three of the action items are dead, and a decision that was made on the call is being re-litigated by someone who wasn't there.

The problem is not that notes weren't taken. It is that notes record what was said. A decision log records what was settled — who decided, on what basis, and what would reverse it. Those are different documents, and only one of them prevents the same meeting happening twice.

Why notes fail

Notes are chronological. They follow the conversation, which is why they are easy to produce and nearly useless later. To answer "did we agree to include the second phase," you have to read five pages in the order they were spoken and reconstruct the answer yourself.

They are also undifferentiated. A remark, a preference, a firm commitment, and a throwaway idea all appear in the same paragraph, in the same font, at the same length. The document does not tell you which one the client will hold you to.

And they are written for the reader of the moment — the person who was on the call and remembers the tone. Six weeks later that person is also reconstructing, with much less fidelity.

What a decision log is

Four fields per decision, and nothing else:

The decision, as one sentence in the past tense. "We will launch in the German market first, not the UK." Not "discussed market entry." Decided, not discussed.

Who decided it. Not who attended. Whose call it was. This matters when the decision is questioned later, and it matters more when the decider is not the person who will feel the consequences.

What it rests on. The evidence or assumption the decision depended on, in one line. If it rested on a number nobody verified, write that down. This is what makes the decision reversible with dignity instead of defensible to the death.

What would reverse it. The specific fact that, if it turned out differently, reopens the question. Deciding without this means every future disagreement becomes a fight about the original call rather than an update on new information.

A log with those four fields settles arguments. A log without them becomes another document that gets skimmed.

The part a model does well

Extraction is genuinely mechanical, and this is where drafting tools earn their keep.

Pulling decisions out of a transcript. Give it the transcript and one instruction: "List only statements where something was decided. Quote the sentence it was decided in. If a topic was discussed without a decision, list it separately as unresolved." The quote requirement is what makes it checkable — you verify the quote against the transcript instead of trusting a summary.

Separating decisions from preferences. "I'd prefer we lead with security" and "we're leading with security" are different, and the gap between them is where scope arguments live. Asking for those to be classified separately is a task with a right answer.

Finding the decisions that contradict earlier ones. Feed it this month's decisions and last month's, and ask for pairs that cannot both hold. This is the highest-value use, because it is exactly what nobody does manually — nobody re-reads last month's log before this month's call.

The failure mode that matters

A model will happily record a discussion as a decision.

Ambiguity in a real conversation looks like this: someone says "we should probably go with the smaller scope," two people nod, the conversation moves on. A summarizer asked for decisions will list that as a decision, because linguistically it is shaped like one and the room didn't object.

Recording it as settled is how you end up three weeks later building the wrong scope, holding a document that appears to show agreement, and being unable to say the agreement was never real.

The rule that prevents this: only a decision whose owner is named in the transcript counts. If you can't point to the sentence where a specific person took it, it goes in the unresolved list. That list is not a failure of the log. It is the most useful part of it, because unresolved items are the ones that will come back.

What it looks like in practice

A real entry, from a call about a website rebuild, looks like this:

Decision: Phase two (the CMS migration) is deferred until the new navigation is live and has been through one full analytics cycle.
Decided by: the client's marketing lead, in the call on the 14th.
Rests on: the assumption that navigation changes will move the numbers enough to justify the migration; nobody has modelled the cost of running both systems in parallel.
Reverses if: the parallel-running cost turns out to exceed the migration cost, or if the navigation change shows no measurable effect after one cycle.
Unresolved: who owns the decision to start phase two when the trigger is met — the marketing lead said "we'll know," which is not an owner.

That entry is worth more than four pages of notes, and it took under a minute to write. Note the unresolved line at the bottom. It is doing as much work as the decision above it: the trigger condition exists, but nobody owns the action, and that is exactly the gap that produces a phase two that either starts by accident or never starts at all.

Compare it with what the notes from the same call would say — a paragraph about the migration timeline, some discussion of the navigation options, and a line about "revisiting phases after launch." Everything needed to reconstruct the decision is technically present, and none of it is in a form that answers a question.

The five-minute habit

The reason decision logs die is that they are treated as documentation, and documentation happens later. It has to happen while the call is still the most recent thing you remember.

The version that survives:

Five minutes after the call, before you do anything else. Paste the transcript, run the extraction, and get a list. Do not read it carefully yet.

Mark the ones you are certain about. These are the decisions where you remember the moment. Delete everything else from the decided list and move it to unresolved — be aggressive here, because a wrong entry costs more than a missing one.

Send the unresolved list to the client the same day. Short, no preamble: "Three things I don't think we settled — [list]. Tell me if I missed a decision."

That last message is the whole mechanism. It converts ambiguity into a question while the call is still fresh, and it does so in a form that is easy to answer. Nobody minds being asked what they decided an hour ago. Everybody minds being told in week five that their decision doesn't count.

What this does not solve

It does not make the client decide. If the unresolved list comes back with "let's discuss next week," you have learned something real: the decision has no owner, and proceeding is a choice you are making on their behalf.

It does not replace the contract. A decision log is an internal instrument and a courtesy to the client; it is not an amendment mechanism, and treating it as one turns a useful habit into a legal argument.

And it will not help if the meetings are the problem — if a decision has to be re-taken every fortnight because the person who owns it keeps changing their mind, the log documents the churn honestly, and the honest documentation is where the conversation about the real problem starts.

The test

Open your last set of meeting notes. Try to answer three questions from them without remembering the call: what was decided, who decided it, and what would change it.

If the notes can't answer all three, they were a record of a conversation, not a record of a decision — and the next meeting is already scheduled to have the same conversation again.

This note describes a method. No time savings, no accuracy rates, and no client engagements are claimed. The failure modes described are properties of summarisation tools, not observations of specific projects.

Related notes