Team decision log: a template that keeps the history
Record what your team decided, the evidence behind it and when to revisit it. A template and worked example for changing course without losing context.
TL;DR: A decision log records the question, evidence, assumptions, options and person responsible for deciding. Add a review trigger and track implementation separately. When the choice changes, create a new record that supersedes the earlier one and explains the new evidence.
Key takeaways
- An assumption remains uncertain even when everyone agrees with it.
- An accepted decision may still be waiting for implementation or verification.
- A new decision should link to the previous one and explain the change without erasing the original reasoning.
Contents
A team decision log explains why an option was chosen and what would justify revisiting it. You need one when somebody works from an old decision, somebody else remembers an exception and nobody can find the original reasoning. The last line in a chat rarely contains all of that context.
For an agency, the log can be a shared document with one record per decision and a short index. Its value comes from keeping the context, separating evidence from assumptions and linking a new decision to the one it replaces. Here is a template and a complete example.
Record decisions that change the work
Create a record when a choice affects several people, depends on a significant uncertainty or would be expensive to reconstruct. Choosing a shared delivery format deserves a record; correcting a typo can stay in the task. Keep decisions that someone will need to understand later.
Write a question that can be resolved: “Which format will we use to present the workshop in the client’s room?” “Improve presentations” does not identify a decision. State what falls outside it: content, session count or attendee materials, according to the scope defined in the proposal.
Separate evidence from assumptions. “The workshop coordinator asked to be able to edit the slides” records a message. “The room’s computer can open the editable file” remains unverified until someone tests it. Agreement does not turn an assumption into a fact.
Name the person preparing and the person deciding
The person gathering information may be different from the person responsible for the final decision. Atlassian’s DACI approach separates those roles, alongside contributors and people who need to know the result. You can keep that distinction in a short record.
Name one person responsible for deciding, those supplying evidence and those affected. Confirm the assignment: typing a name into a cell neither grants authority nor demonstrates acceptance. If you need an external response, leave that dependency visibly pending.
Each option needs concrete consequences. “Use the editable file”, “present a PDF” and “defer the choice until the room test” let you compare the benefits, outstanding work and possible blockers. Do not add alternatives that nobody considered simply to justify the preferred option afterwards.
A template with two separate statuses
Copy this record and replace the bracketed instructions. Use short references such as DEC-01 and DEC-02 in both the index and related tasks. These are internal example identifiers, with no particular software required. Link to evidence the team can access without copying credentials or unnecessary information.
Reference and question: [identifier / specific decision]Scope: [work affected / what is excluded]Preparation: [person gathering information]Decision owner: [person / confirmed assignment]Contributors and recipients: [who contributes / who needs to know]Evidence: [fact / reference / date checked]Assumptions: [what needs checking / owner / consequence]Options: [real alternatives and their consequences]Outcome: [chosen option and reason; or pending]Decision: [proposed / accepted / rejected / superseded]Confirmation: [person / date / reference; or pending]Application: [effective from / required condition]Review: [trigger / date / owner]History: [supersedes / superseded by / dated note]Implementation: [pending / in progress / blocked / verified]Next action: [task / owner / date or condition]Verification: [expected result / evidence / owner]Accepted means the decision has been confirmed. Verified describes its implementation, supported by the required evidence. A rejected decision should not proceed to implementation. If the decision is deferred, leave it “proposed”, record what is missing and assign someone to resolve it. Silence does not complete the confirmation.
Worked example: new evidence changes the decision
Fictional scenario. An agency is preparing a workshop. The references, days and results below are illustrative, not a real client’s experience. Workshop content has been agreed. The remaining choice concerns the file used during the presentation.
| Record | DEC-01, day 1 | DEC-02, day 3 |
|---|---|---|
| Evidence | The coordinator requests editable slides until the day before the workshop. | A room test shows that the available computer opens PDFs but cannot open the editable file. |
| Assumption | The room’s computer will open the editable file; a test is pending. | The PDF will preserve the necessary content; the final export needs checking. |
| Confirmed decision | Prepare the editable file; its use in the room depends on the test. | Present the verified PDF and retain the editable file for working changes. |
| Decision owner | Workshop lead, with the assignment confirmed. | The same person confirms the change after consulting the presenter. |
| Review trigger | Result of the room test. | Content changes after the PDF has been checked. |
| History | Superseded by DEC-02 on day 3. | Supersedes DEC-01; the test disproves its assumption. |
| Implementation at the end of day 3 | Use of the editable file in the room was never cleared. | Export prepared; PDF verification still pending. |
DEC-02 has been accepted, but you still cannot record “presentation verified”. The next action is to open the final PDF on the room’s computer and check the intended slides. If the workshop depends on an animation lost during export, the test needs to reveal that before the format is cleared for use.
The approach to preserving reasoning draws on the architectural decision records, or ADRs, described by AWS: a new decision can supersede an earlier one. Here we adapt that idea to service operations, rather than treating an architecture process as a workshop standard.
Keep the original facts and reasoning in DEC-01. Add a dated note linking to DEC-02. A reader can then distinguish a reasonable choice made under an explicit assumption from a mistake concealed by rewriting the past.
Review when a specific condition changes
“We will revisit this later” gives nobody anything to watch for. A failed test, a changed dependency or a new requirement can trigger a review. Assign someone to monitor that condition and a date to check it when the work has a deadline.
The date does not automatically retire the decision. Without new information, record whether it remains applicable and which checks are outstanding. Where proceeding depends on an unmet condition, keep the blocker visible. Accepting DEC-01 did not authorise skipping the equipment test.
Fixing a typo does not require DEC-03. Changing the chosen format or its conditions of use deserves a new reference. If evidence was recorded incorrectly, add a dated correction and review the consequences; do not leave the log supporting a false certainty.
Check that another person can continue
Keep an index with the reference, question, current decision and a link to its history. Point implementation tasks to the decision that applies. When it changes, notify the people affected and check that whoever has outstanding work received the new reference. Updating a document does not mean everyone has read it.
Ask someone outside the original conversation to find three things: what needs doing now, why the decision changed and what remains pending. If they need to ask you, improve the record. If the log creates unnecessary maintenance, apply the principle of eliminating, automating and delegating before adding another recurring task.
Start with one current decision whose reasoning is difficult to recover. Write down what is known, flag what remains an assumption and give the next action an owner. The next person should be able to continue from there.
Was this article helpful?
FAQ
Should we record every team decision?
Record choices that change shared work, depend on an important assumption or would be difficult to reconstruct. A minor choice that is easy to reverse can stay in the relevant task.
What happens when the review date arrives without new information?
The date prompts a review; it does not automatically retire the decision. Record whether it still applies, what evidence is missing and who will obtain it. If continuing requires an unmet condition, keep the blocker visible.
Can I update the old document when the decision changes?
Keep the original reasoning and evidence. Add a dated note linking to the new decision and mark the earlier one as superseded when appropriate. Distinguish an editorial correction from a change in the decision itself.
