# How to keep a decision log for client projects

> For freelancers and consultants whose clients reopen questions everyone thought were settled: what a decision log is, why client decisions get relitigated, the fields each entry needs, a copy-paste template with worked entries, how to capture decisions during Google Meet and Microsoft Teams calls, how to change a decision without rewriting history, and how to use the log when one is challenged.

Canonical: https://trackheros.com/blog/decision-log-for-client-projects/  
Author: Sami Kanafani  
Updated: 2026-10-22

**In short:** A decision log is one running list per client project of what was decided, when, by whom, why, and what was rejected. Add each entry the day it is made, never edit an agreed entry, and supersede it with a new one instead. TrackHeros writes a decisions section into the summary of every Google Meet and Microsoft Teams call, ready to copy into the log.

A decision log is a single running list of the decisions made on a project: what was decided, when, by whom, why, and what was rejected. This guide is for freelancers and consultants whose clients reopen questions everyone thought were settled, and whose decisions are mostly made in calls on Google Meet or Microsoft Teams. It covers why decisions get relitigated, what an entry needs, a template to copy, how to capture decisions in a meeting, and how to change one without rewriting history.

## What is a decision log?

A decision log is one list per project, in date order, where each entry is a decision made by someone with the authority to make it. It is different from minutes, which record one meeting, and from a task list, which records what people will do. The log records what is now true about the project: which provider, which scope, which date.

Minutes are where a decision first appears. The log is where it lives afterwards, next to every other decision, so the current state of the project can be read in one place instead of being reconstructed from twelve sets of minutes. The [difference between minutes and notes](/blog/meeting-minutes-vs-meeting-notes/) covers the other records around it.

## Why do client decisions get relitigated?

Because the record is missing, vague, or missing the reason. Rarely because anyone is acting in bad faith.

| Cause                    | What happens                                        | What the entry needs             |
| ------------------------ | --------------------------------------------------- | -------------------------------- |
| Nobody wrote it down     | Your memory against theirs                          | A dated entry, made the same day |
| A new person joins       | They were not there and see no reason for it        | The reason, in a sentence or two |
| The reason was lost      | The decision looks arbitrary six weeks later        | Why, and what was rejected       |
| It was vague             | "Something like the hosted option" means two things | One specific sentence            |
| The wrong person decided | Their manager reverses it                           | Who decided, and in what role    |
| It was never confirmed   | One side heard a decision, the other heard an idea  | A status: proposed or agreed     |
| Circumstances changed    | A fair reason to revisit                            | A "revisit if" line              |

The last row matters most. Some decisions should be reopened. A log that records what would justify reopening one turns a challenge into a check: has that condition happened or not?

## What should a decision log entry contain?

Nine fields, most of them one line. The two that do the work are "why" and "revisit if"; the rest make the entry findable.

| Field      | What to write                            | Example                                                                |
| ---------- | ---------------------------------------- | ---------------------------------------------------------------------- |
| ID         | D-001, D-002 and so on, never reused     | D-003                                                                  |
| Date       | When it was made                         | 2026-10-19                                                             |
| Decision   | One specific sentence, past tense        | Go-live moved to 10 November 2026                                      |
| Why        | One or two sentences                     | Staging access arrived a week late; the deploy needs five working days |
| Rejected   | Alternatives that were argued for        | Keep 3 November and drop the refunds work                              |
| Decided by | Name and role                            | Priya, product owner                                                   |
| Source     | Where it happened                        | Weekly call, 2026-10-19, minutes item 2                                |
| Status     | Agreed, superseded by D-0xx, or reversed | Agreed                                                                 |
| Revisit if | The condition that would reopen it       | Production access is ready before 31 October                           |

## What does a decision log template look like?

Two layouts work. A table is easy to scan when entries are short. One heading per decision suits longer reasoning and sits well in a repository next to the code.

```markdown
# Decision log — [Client] — [Project]

| ID    | Date       | Decision                     | Why                                 | Decided by      | Source                  | Status              |
| ----- | ---------- | ---------------------------- | ----------------------------------- | --------------- | ----------------------- | ------------------- |
| D-001 | 2026-10-06 | Hosted search for phase one  | Nobody on the client side to run it | Priya (product) | Kickoff, 2026-10-06     | Agreed              |
| D-002 | 2026-10-06 | Go-live on 3 November 2026   | Ahead of the client's campaign      | Priya (product) | Kickoff, 2026-10-06     | Superseded by D-003 |
| D-003 | 2026-10-19 | Go-live moved to 10 November | Staging access arrived a week late  | Priya, with Tom | Weekly call, 2026-10-19 | Agreed              |
```

```markdown
## D-003 — Go-live moved to 10 November 2026

- **Date:** 2026-10-19
- **Decided by:** Priya (product owner), with Tom (engineering lead)
- **Source:** Weekly call, 2026-10-19, minutes item 2
- **Why:** Staging access arrived a week late; the deploy needs five
  working days from access.
- **Rejected:** Keeping 3 November and dropping the refunds work.
- **Supersedes:** D-002
- **Revisit if:** Production access is ready before 31 October.
- **Status:** Agreed
```

## How do you capture decisions during a call?

Say the decision back, check who is deciding, and write it down before the conversation moves on. Three short sentences do most of the work.

```text
"So the decision is hosted search for phase one. Is that right?"
"Priya, is that yours to decide, or does someone else need to agree?"
"I'll log it, with the reason: nobody on your side to run a search cluster."
```

The second question feels awkward the first time and saves weeks later. A decision made by someone without the authority to make it is the kind most likely to be reversed.

Then sort what you heard. A decision changes scope, cost, a date, the architecture or who owns something, or it rules an option out. "We like the blue one", "let's look into caching" and "it would be nice if" are not decisions; they belong in the notes or become [action items](/blog/how-to-write-action-items/).

The same day, copy each decision from the [minutes](/blog/how-to-write-meeting-minutes/) into the log, give it an ID, and put the ID back in the minutes. Decisions made by email or chat count too: log them with the message as the source.

## How do you change a decision without rewriting history?

Add a new entry that supersedes the old one, and mark the old one "superseded by". Never edit or delete an agreed entry.

An edited log is worthless as evidence, because nobody can tell what it said before. An append-only log shows the decision, the change, and the date and reason for both, which is usually exactly what a client's new manager needs to see. If an entry was simply wrong, a misheard date for example, add a correcting entry rather than fixing the old one quietly.

## How do you use the log when a decision is challenged?

Quote it, offer to change it, and log the change. The log is not there to win arguments; it is there to make a change deliberate rather than accidental.

```text
"We decided that on 6 October, D-001 in the log. The reason then was that
nobody on your side could run a search cluster. If that has changed, we can
make a new decision now, and I'll set out what it does to the dates."
```

The last clause is what connects the log to scope. Reversing a decision usually costs time, and the moment it is reversed is the moment to say so; [scope creep starts in meetings](/blog/scope-creep-starts-in-meetings/) has the change-request side of that conversation.

## Where should a decision log live?

Somewhere both sides can read, one per client: a shared document in the client's workspace, a `docs/decisions.md` file in the repository, or a page in the client's wiki. Not in your own notes app where the client cannot see it, and never in one list across several clients; [keeping client notes separate](/blog/keep-client-meeting-notes-separate/) explains why.

## How does TrackHeros help keep a decision log?

TrackHeros does not keep the log for you, but it does the capture. The summary of every Google Meet or Microsoft Teams call it joins has a decisions section listing each decision that was actually stated, filed in that client's workspace. Copy them into the log the same day.

When a decision is challenged months later, the per-client assistant answers questions such as "when did we agree to move go-live?" from that client's meetings only, with citations to who said it and when, linking to the moment in the recording. Search across every client labels each result with its client. More on [asking your meetings](/features/ask-your-meetings/) and on the [minutes](/features/meeting-minutes/).

## Frequently asked

**What is the difference between a decision log and meeting minutes?**

Minutes record one meeting; a decision log records one project. Minutes hold everything agreed in a call, including actions and open questions. The log holds only decisions, from every meeting, email and chat, in the order they were made, so the current state of the project can be read in one place.

**Should small decisions go in the log?**

Only if someone could reasonably reopen them, or if they change scope, cost, dates, architecture or who owns what. A button colour probably does not belong; a choice of payment provider does. If a question took more than five minutes to settle, log the answer.

**What is an architecture decision record?**

A short document, common in software teams, recording one technical decision with its context, the options considered and the consequences. It is a decision log entry with more room for the reasoning. A freelance developer can keep both: decision records in the repository for technical choices, and a decision log for everything the client decided.

**Who should keep the decision log?**

Whoever writes the minutes, which on a client project is usually the freelancer. Share it with the client read-only, or paste the newest entries into each follow-up email, so it is a record both sides have seen rather than your private version of events.

---

TrackHeros is in early access: https://trackheros.com/#early-access