At a glance
A client decision log records the choice, who confirmed it, why it was made, and what work follows. Use one entry per meaningful decision, link to the confirmation, and label proposals separately. If a later decision replaces an earlier one, connect the two entries instead of overwriting the history.
A client decision log is a short record of meaningful choices: the question, the agreed answer, the person who confirmed it, the reason, and the next action. Use it when an approval affects the work, timing, or responsibilities. Keep suggestions and unresolved questions separate from confirmed decisions.
Which conversations need a decision record?
Record choices that another person may need to understand later: a selected concept, an agreed content direction, a changed deliverable, or a decision to postpone part of the work. You do not need a separate entry for every typo correction or informal preference.
The useful test is: “Would somebody need this context to continue the project without me?” If the answer is yes, record the decision close to the work and link to the message or document that confirms it.
Atlassian’s DACI decision-making framework separates the person organizing a decision from the approver, contributors, and people who need the outcome. For a small freelance project, you can use that distinction without adopting every part of the framework. Confirm whose answer counts before treating a comment as approval.
A copyable client decision log template
| Field | What to write |
|---|---|
| Decision ID and project | A short stable reference, such as D-04, and the project name |
| Question | The specific choice that needs an answer |
| Status | Proposed, awaiting confirmation, confirmed, or superseded |
| Decision and date | The confirmed answer and when it was confirmed |
| Approver and contributors | Who confirmed it and whose input informed it |
| Reason and alternatives | Why this option was selected and the meaningful tradeoff |
| Confirmation | A link or precise reference to the original message or document |
| Effect and next action | What changes, who acts, and the relevant date |
Use one entry per decision, not one entry per meeting. A meeting can contain three decisions and two unanswered questions; combining them into “the client approved everything” loses the distinction.
Worked example: choosing the first page to redesign
Imagine a freelancer helping a consultancy improve two service pages. The team needs to choose which page goes first. The following names and project are illustrative.
- Decision: D-04: redesign the advisory service page first.
- Status and date: Confirmed on September 8.
- Approver: Morgan, the client’s named project owner. The sales lead supplied input.
- Reason: The advisory page has approved copy and is needed for an upcoming campaign. The training page still needs content decisions.
- Alternative considered: Start with training. Deferred because its copy is not ready.
- Confirmation reference: Morgan’s reply in the project’s September 8 planning email. The real log would link to that message.
- Effect: The order changes; the agreed number of pages and overall scope remain the same.
- Next action: The freelancer prepares the advisory page outline for review on September 10.
The record explains what was decided and what was not. It does not imply that the whole website was approved or that a larger redesign was added. If the request changes the agreed scope, handle that separately before scheduling the added work. See how to respond when a client asks for one more thing.
Turn a vague reply into a clear confirmation
“Looks good” may mean “I like the direction,” “my comments are finished,” or “you can publish.” State the decision you need before asking for a response. For example:
Please confirm that the advisory page should be the first page we redesign. The training page will follow once its copy is ready. This changes the order only; the agreed deliverables remain the same.
Use the actual confirmation channel and approval process agreed with the client. A decision log organizes the record; it does not create signing authority, replace an agreement, or prove that somebody approved something they did not approve.
For broader communication habits, use the guide to setting clear client expectations. The log works best when the people involved already know how decisions will be requested and returned.
What if the client changes the decision?
Add a new entry and point back to the earlier one. Mark the earlier decision “superseded by D-07,” then explain what changed and what the new answer means for unfinished work. Preserve the original confirmation rather than editing the old record to look as though the new choice was always agreed.
If a comment conflicts with an existing decision, pause the affected action and ask the named approver to resolve it. Other work may continue if it does not depend on that choice. For overdue answers, keep a specific next follow-up using the waiting-on-client approach.
Keep the record close to the client work
For a small project, a shared document or spreadsheet is enough. In ProjectBook, use the project description for project-specific context, customer notes for durable relationship context, and tasks for follow-up work. The customer workspace keeps those customer records accessible; it is not an external approval portal or a dedicated decision-log feature.
Keep access appropriate to the material. Record the business decision and necessary context rather than copying an entire sensitive conversation into every note. Review open decisions at your next check-in, and browse the client relationships guides for handling feedback and handoffs.
To carry a confirmed choice into the work itself, use the meeting-notes action template to identify owners, dependencies, and the next check-in.
From ideas to a clearer week