How to track decisions across meetings with a decision log that fills itself

A decision log is the list of what a project has settled: which provider, which scope, which date. This guide is for freelancers, consultants and project leads who make those decisions with clients on Google Meet and Microsoft Teams, and who would rather not copy each one out of the minutes by hand. It covers a decision log kept as a table that fills itself after every meeting. The manual method, with the fields, a template to copy and how to supersede an entry, is in how to keep a decision log for client projects.

Why do decisions get lost between meetings?

Because each one is written down once, in the minutes of the meeting where it was made, and nowhere else. Twelve meetings later the current state of the project is spread across twelve documents, and finding out whether hosted search is still the plan means reading all of them.

A log fixes that only if somebody keeps it, and the copying is the step that slips first. A month later the log is three weeks behind and nobody trusts it.

What is the Decision log template?

It is one of the six templates TrackHeros offers when you start a tracker: a table with one row per decision, kept up to date meeting after meeting. TrackHeros is an AI meeting notetaker that connects every Google and Microsoft calendar you hold, recognises close to 100 spoken languages on its own, writes the notes in nine of them, and keeps every client's notes in a sealed workspace of its own. A tracker is a table that fills itself from those meetings.

Column	Type	What goes in it
Decision	Text, names the row	A decision the meeting made or confirmed, in a short sentence; not proposals still under discussion
Context	Text	Why it was made, in one sentence
Decided by	List of people	The people who made it
Date	Date	When it was made
Status	Status	Active, Reversed or Superseded

Each column carries a one-line description, and that description is what TrackHeros reads when it decides what belongs in a cell. The template is the manual entry cut down to what a meeting can reliably supply. Rejected alternatives and a "revisit if" condition are rarely said in a form worth recording, so they are not columns by default. You can add them: adding columns to a template counts as designing your own tracker, and pricing says which plans include that.

How does a decision get from the call into the table?

After the meeting's notes are ready, TrackHeros reads the meeting against the table and proposes what it found: a new row for each decision stated, and changes to rows already there. Every value has to point at the transcript lines it came from, and a value with no line behind it is dropped.

1. The meeting ends and the notes are written. For a meeting that goes through the audio pass, such as one held in another language or in two, the tracker waits for that pass so the meeting is read once.
2. TrackHeros reads the notes and the relevant passages of the transcript, with the table's columns and existing rows in front of it.
3. Each proposed value is checked against the lines it cites. The quote you see is rebuilt from the stored transcript, never written by the model.
4. The proposals wait in the tracker's review tab, grouped by meeting, and the meeting's own page lists what it gave each tracker in a "What changed" panel.

The model is told to fill only what the meeting actually says and to leave the rest empty. A decision with no stated reason gets an empty Context cell, not a plausible one. Meetings in any of the languages TrackHeros recognises are read the same way, from the same transcript as the notes.

Which meetings should feed a decision log?

Usually every meeting of one client, because decisions get made in whichever call the question comes up in, not only in the formal ones. Meetings plainly unrelated to the tracker's subject are skipped, so a call about an invoice does not have to be excluded by hand.

Narrower scopes suit narrower habits: only meetings whose titles contain "steering" or "review", a chosen recurring call such as the weekly status meeting, a one-off workshop you attach the tracker to before it happens, or nothing at all until you send a meeting by hand.

There is also a scope for all your clients: one definition, with a separate table kept for each client and shown together, a client label on every row. Rows from two clients are never merged, even when two decisions have the same wording, so a decision made for one client never turns up in another client's log. Client isolation explains the walls; pricing says whether your plan includes all-clients trackers.

What happens when a decision is reversed or replaced?

The row stays, its Status changes, and the history keeps the earlier value beside the new one. Nothing is overwritten. The manual guide's rule, never edit an agreed entry, is simply how every cell already works.

Take a fintech client that settles on hosted search at the kickoff and changes its mind a month later:

Meeting	Row	Value	Words used
Kickoff, Monday 2 February 2026	Hosted search for phase one	Status: Active	"Let's go with hosted search for phase one. Nobody here can run a cluster."
Weekly call, Monday 2 March 2026	Hosted search for phase one	Status: Superseded	"Now that Tom's team is joining, we'll run search ourselves."
Weekly call, Monday 2 March 2026	Self-hosted search from phase one	New row, Status: Active	The same line

A meeting that replaces a decision can produce two proposals at once: Superseded on the old row and a new row for the new decision. Both wait for you in review. A meeting that repeats a decision is recorded as a confirmation, not a change, so the row's history shows that it was reaffirmed, and when.

An older meeting never overwrites a newer value. If last month's workshop is sent to the log after this week's call, its value lands in the history, labelled as older, and the table keeps the newer one.

How do you show where a decision came from?

Open the cell's history. Every value records the meeting it came from, who said it, when in the meeting, and the words they used; a link opens the transcript at that moment, and the recording jumps there.

That is the part of a decision log that is tedious to keep by hand and decisive when a decision is challenged: instead of "we agreed this in February", you point at the sentence, the speaker and the minute. More in a history of every change, with the quote.

The assistant reads trackers too. Ask "what did we decide about search, and when?" in the client's chat and the answer comes from the table, with the meeting each value came from. It reads the log; it does not change it. Ask your meetings covers what else it answers.

Should decisions go straight into the log or wait for review?

Wait, at least at first. By default every new or changed value sits in a review queue: accept it, edit it and then accept, reject it, or accept everything from one meeting at once. The tracker's creator gets an in-app alert when changes are waiting.

A decision log is a record people quote back at each other, so a wrong entry costs more than a missing one. A tracker can be set to apply confident values on its own, but even then a possible duplicate row and a change to a cell somebody edited by hand wait for a person. A rejected value does not come back when the same meeting is read again.

Editing a cell protects it: later changes from meetings go to review instead of replacing your wording. You can also restore an older value, undo a change that was applied, and add a row yourself, which is how a decision made by email gets in.

How do you start a decision log with history already in it?

When you create the tracker, have it read your recent past meetings in scope. They are read oldest first, so each decision's history builds up in the order it happened and the table starts with the project's past instead of empty.

Before saving, preview the definition on one recent meeting. If the preview treats an idea as a decision, tighten the Decision column's description first.

What does the decision log not do?

It reads recorded meetings, after they end, and nothing else. Nothing is filled during the call. Email and chat are not read, so decisions made there are rows you add. Rows are not sent to other tools; the table and its full history download as CSV for Excel or Google Sheets, and pricing says which plans include export.

Each log belongs to one client. Deleting the tracker deletes its table and every value and quote; deleting the client deletes its trackers.