meeting workflows
Meeting Decision Log Template: Keep the Evidence
A meeting decision log records the choices a team actually made and the evidence that supports them. It is different from a summary of everything discussed and different from a task list. Keep those records connected without treating them as interchangeable.
For each decision, state the choice, its scope, who confirmed it, when it was made, and why. Add the relevant transcript quote or source location when available. Keep unresolved questions beside the decision so later readers do not mistake a bounded choice for a universal rule.
Define what counts as a decision
A decision needs a supported final state. “We discussed changing providers” is a topic. “We will test provider B for this non-production workflow” can be a decision if the authorized people confirmed it. The scope matters: a test is not the same as replacing the production provider.
Use status labels that reflect the conversation. Proposed, agreed, superseded, and reopened can each be useful. Do not use agreed merely because an AI summary supplies decisive wording.
If the person with authority was absent or approval remains pending, record that condition. A meeting can prepare a recommendation without completing the final decision.
Capture a compact record
Use a decision identifier, title, date, scope, owner, rationale, evidence, and review condition. The identifier can be a simple project-specific sequence; it does not need a complicated system.
For an illustrative record, a team might choose a two-week pilot for one internal workflow, assign a review owner, and define completion evidence. State exactly which workflow is included and which question the pilot will answer. Avoid turning that example into a claim that a particular tool has already been adopted.
Keep the rationale concise. Explain the relevant constraints and alternatives rather than copying the entire discussion. Link to the supporting material with access appropriate to the people who need it.
Preserve the evidence and its limits
Copy a supporting quote exactly when the record includes quotation marks. Check the surrounding discussion for qualifications or later changes. If a statement was hypothetical, the decision record must not present it as an authorization.
Note any transcription uncertainty that affects the decision. Names, negations, dates, and amounts deserve particular attention. Use the summary verification checklist before promoting a generated note into the log.
Do not expose a private meeting transcript through a public citation link. A decision record can point to a controlled source location. Sharing the record and sharing all underlying discussion are separate access decisions.
Separate follow-up work from the choice
A decision may create tasks, but those tasks need their own owners and dates. Link to the meeting action items instead of hiding assignments in the rationale paragraph.
For example, approving a pilot does not establish who will create the test environment, arrange the review, or collect evidence. Confirm those responsibilities separately. The action list should show the work required to carry out the choice.
If a task becomes blocked, update the task's status. Do not rewrite the original decision as though it had never been made. The log should help explain the relationship between the agreed choice and its implementation.
Define when the decision is reviewed
Record the event or evidence that would reopen the choice: pilot results, a changed requirement, a missed assumption, or a scheduled review. Avoid reopening a settled matter simply because a later reader did not see the original rationale.
When a new decision supersedes an old one, link the records and preserve the earlier state. The history is useful when someone asks why the system or process changed. Silent replacement loses that explanation.
Review the log during relevant project checkpoints. Carry unresolved conditions forward with their owners, and close them only when the required evidence or approval exists.
Keep the record near the work
Store the log where the team already plans and reviews the project. Make it discoverable to the people expected to follow it. A precise decision record hidden in a personal notebook cannot coordinate the team.
Use TeamMeet to capture the conversation and transcript-linked notes, then confirm and store the decisions through the team's chosen process. For clear participant attribution, each person should join with their own microphone connection; a shared stream does not separately identify everyone in the room.
Prepared with AI assistance. Examples are illustrative; confirm consequential claims against the source record and with the participants.
Sources
The task and decision templates are original planning examples. Product references are grounded in the TeamMeet homepage, developer documentation, and privacy policy. Review the actual meeting record and participant confirmation before treating an example as a commitment.