Debrief a Meeting

Turn a completed meeting into a clear view of what changed and what follow-through is now required.

Base the debrief on what was actually said and recorded.

Do not convert discussion into decisions or suggestions into commitments.

1. Choose the right workflow boundary

Use this workflow for general meeting debriefs.

When the meeting is primarily about:

• account qualification;
• pipeline;
• opportunity;
• commercial judgment;

use the sales-meeting debrief workflow.

When the meeting is a candidate interview requiring scorecard assessment, use the interview-feedback workflow.

Continue here for general meetings and non-specialist follow-through.

2. Match the correct meeting and record

Identify:

• meeting;
• participants;
• purpose;
• desired output.

The user may need:

• quick recap;
• decisions;
• actions;
• follow-up message;
• system updates;
• fuller debrief.

Start with the smallest useful result.

Where possible, resolve the meeting calendar-first.

Match:

• event;
• transcript;
• recording;
• notes

using:

• timing;
• attendee names;
• email addresses;
• organization;
• project context.

If no reliable record exists, use user-provided notes and clearly state the limitation.

Do not reconstruct detailed outcomes from a calendar title or memory alone.

3. Treat meeting records as evidence, not perfect truth

Use the full record when details matter.

Identify speakers carefully.

Flag uncertain:

• wording;
• attribution;
• speaker labels.

Bring in prior:

• messages;
• documents;
• project records;
• calendar context

only when they help interpret a reference or commitment.

Keep these distinctions explicit:

• discussed ≠ decided;
• requested ≠ committed;
• suggested owner/date ≠ accepted owner/date;
• private note ≠ shared meeting outcome.

When sources conflict, show the conflict.

Do not choose the version that is easiest to operationalize.

4. Identify what changed

Focus on what should affect work after the meeting.

Look for:

• accepted decisions;
• changed assumptions;
• commitments;
• owners;
• due dates;
• dependencies;
• open questions;
• unresolved choices;
• blockers;
• risks;
• promised documents;
• promised introductions;
• promised answers;
• systems that no longer match the accepted outcome.

If nothing material was decided, say so plainly.

Do not force a meeting into an action-oriented structure when it was exploratory.

5. Prepare the useful debrief

Lead with a concise outcome summary.

Add only the components the user needs, such as:

• what changed;
• what did not change;
• accepted decisions;
• supporting evidence;
• owned actions;
• due dates;
• unresolved questions;
• next decision point;
• follow-up message;
• proposed system updates.

Keep important source moments or links close to consequential claims.

Separate:

• shared recap;
• private notes;
• sensitive hypotheses.

If a promised asset or answer is missing from the record or approved company material, leave the gap visible.

Do not invent it.

6. Keep follow-through actions separate

Treat each of these as separate actions:

• debrief creation;
• follow-up message;
• task assignment;
• project update;
• document update;
• calendar update;
• external system update.

Before acting, show:

• person or record;
• destination;
• proposed change;
• scope.

After approved updates, verify results when possible.

Report anything still blocked or unresolved.

7. Route ongoing commitments appropriately

Use the open-loop workflow when commitments need tracking beyond immediate follow-through.

Use meeting preparation when the next meeting should carry forward accepted decisions and unresolved questions.

8. Improve future debriefs

Use feedback to learn:

• preferred depth;
• note structure;
• tone;
• destinations;
• review behavior.

Do not turn one meeting's structure into a permanent rule.

When the pattern proves durable, preserve it as a reusable skill.

Recurring debrief automation may be appropriate when:

• meeting records arrive reliably;
• calendar matching is stable;
• sources are defined;
• review is required.

It should stop when:

• meeting identity is unclear;
• speaker matching is unclear;
• record is incomplete;
• private context could be exposed;
• follow-up depends on a decision only the user can make.