Write a Meeting Decision Recap Without Inventing Agreement
Record what was decided, what is still open and who agreed to do what. A recap should preserve the meeting's limits, not turn a suggestion into a commitment.
Miles Crawford
Start with the outcome, not the conversation
A meeting decision recap is a short record of choices made, questions left open and agreed next steps. It is different from a transcript, a personal scratchpad or a new proposal. Someone who missed the meeting should be able to tell what changed without guessing which comments became decisions.
Atlassian's meeting-notes guidance recommends sharing a recap and adding due dates to agreed action items. Its meeting-minutes template distinguishes discussion summaries, decisions and actions. Our suggested format below keeps those categories separate. It is an editorial aid, not a required Slack or Teams template.
Use four labeled blocks
Context: name the meeting, date, purpose and link to the approved work record. Add only the background needed to understand the outcome.
Decided: state the choice, its scope, the person or role that made it, and any conditions. Include the reason if it explains a tradeoff or prevents a likely misunderstanding.
Still open: list unresolved questions and proposals. State what evidence or decision is missing. If no decision was made, say so instead of forcing a positive outcome.
Agreed actions: name the deliverable, accepted owner, agreed date and where progress belongs. If ownership or timing was not agreed, label it unassigned or unconfirmed and ask the relevant person through the team's normal process.
GitLab's live-document meeting guidance says notes need not be verbatim, but should capture key points and be clear on decisions or next steps. That supports a concise record, not stripping away qualifications that change what people agreed.
A decision check before you write 'we agreed'
Ask what evidence supports the sentence. Did the authorized decision-maker choose the option? Was a condition attached? Was the date accepted, or merely suggested? A room moving to the next agenda item is not enough for the recap author to decide the answer.
GitLab documents its own distinction between gathering input and making a decision, with an assigned directly responsible individual. Your organization may use a different model. Identify the actual decision route instead of assuming a majority vote, a manager's preference or a chat reaction settles every question.
Keep the wording at the right level
- A possibility
- Instead of "We will switch vendors", write "We discussed switching vendors. No choice was made."
- A conditional choice
- Instead of "The launch is approved", write "The launch was approved only if the access review passes."
- A next step
- Instead of "The team will fix it", name the accepted owner and the specific agreed deliverable. If neither was agreed, say that the action remains unassigned.
This comparison is an editorial check, not a product rule.
Fictional recap: a small pilot, not a full rollout
All names, projects, records and relative dates in these examples are invented. Replace placeholders with verified details before using the wording.
Context: Support handoff review, [full meeting date]. Goal: choose the next test for the revised checklist. Record: [approved work item].
Decided: Priya approved a pilot with the morning support shift only. The pilot does not change the other shifts' process. Reason: check whether the two new escalation fields are usable before considering a wider rollout.
Still open: no wider rollout date was agreed. The evening shift's requirements still need review.
Agreed action: Lee will prepare the pilot checklist draft by [agreed full date]. Done means a reviewable draft in [work item], not a published process. Priya will review it at [agreed checkpoint].
Notice the boundaries: pilot is not rollout, a draft is not a release, and one person's accepted task is not a team-wide assignment. The recap records those limits rather than relying on readers to remember them.
When the meeting did not reach a decision
Try: We compared the two export layouts but did not choose one. The open question is whether the customer code is required. Morgan will confirm that requirement in [work item] by [agreed date]. The layout decision remains open until the decision owner reviews the answer.
If Morgan did not accept that action, do not attach their name to it as a commitment. Write: Requirement check still needs an owner. I will ask the project lead to confirm who can take it. Use that final sentence only if you actually intend to do the asking.
Avoid 'unless anyone objects, this is approved' unless the team's established decision process really gives silence that meaning. A deadline to correct notes is not automatically a deadline that authorizes a new plan.
Check action items for a visible finish
Atlassian's action-item guidance lists the owner, action, scope, outcome, deadline and source. Use that as a review aid, not a reason to invent a missing date. A useful action describes the next deliverable: 'draft the two error messages for review' is different from 'fix onboarding'.
Keep proposed work apart from accepted work. Add the relevant dependency and link to the work record. If the date is provisional, label it. If no date was agreed, leave the gap visible and ask for one rather than silently converting a suggestion into a promise.
Review automated notes and the audience
Microsoft warns that AI-generated content in Teams intelligent recap can be inaccurate, incomplete or inappropriate. Its recap-email instructions also say to edit the drafted email for accuracy and review recipients. Treat an automated summary as material to check, not independent proof that a person accepted a task.
Check consequential names, dates, scope and decision status against permitted meeting notes or the decision-maker. Do not start recording, transcribing, installing a bot or buying a license just to use this writing format. Follow workplace rules for recordings and confidential material.
Before sharing, check both the chat audience and linked-document access. A readable sentence can still disclose restricted customer, staffing or commercial information. Include only what that audience is allowed to see. A link in a recap does not by itself mean every reader has permission to open it.
Correct the record without creating two final answers
If someone spots an error, verify the disputed point with the right person. Correct the work record and make the change visible to affected readers through the team's agreed route. For example: Correction: the pilot covers the morning shift only, not all support shifts. I have corrected the recap and linked work item. The wider rollout is still undecided.
That is a correction to what happened, not a fresh decision. When the plan really changes later, record the new decision, who made it and which earlier instruction it replaces. Do not quietly edit yesterday's recap so it looks as if the new plan was always agreed.
For finding the native notes or recap interface, see our separate meeting-notes guide. For keeping an agreed choice easy to find, see the pin-decisions guide. Neither visibility nor a reaction proves that the underlying decision was authorized.
Sources and limits
Sources checked October 31, 2026. Format, decision check, comparison aid and examples are original editorial suggestions, not a measured productivity claim. Official workplace practices are attributed to their organizations, not universal rules. No signed-in Slack or Teams behavior, recording workflow or message delivery was tested for this guide. This is a routine work recap, not advice on legally required board minutes or regulated records. The generated artwork is conceptual, not a screenshot.