Claude Prompt Templates for Meeting Summaries

Picture this: a 60-minute cross-functional strategy meeting ends. Everyone leaves having discussed the same topic from three different angles. Three days later, one team has started executing on the version they heard. Another team is waiting on a decision they thought was tabled. The third team thought nothing was decided at all. This isn't a meeting culture problem -- it's a summary problem. And it's the specific problem a well-built claude prompt template for meeting summaries is designed to fix.

The Problem a Project Manager Faced

A project manager at a product company ran eight recurring meetings per week across five stakeholder groups. She was writing meeting summaries manually, averaging 20-25 minutes per meeting, and still finding that the summaries were frequently disputed -- different attendees remembered different things as having been decided versus discussed versus deferred.

The disputed summaries weren't inaccurate. They were ambiguous. When she wrote "we'll revisit this next quarter," it left open who owned the revisit, what would trigger it, and whether it was a decision or a discussion topic. When she wrote "team agreed to prioritize the mobile feature," it didn't capture the conditional -- agreed to prioritize, assuming the API dependency was resolved by end of month.

The Wrong Approach

Summarize this meeting transcript.

This produces a coherent chronological summary of what was discussed. It will generally be accurate to the discussion. It will miss the most important structural distinction in any meeting output: the difference between what was decided (binding, someone owns it), what was discussed (informational, no owner, may or may not become a decision), and what was explicitly deferred (acknowledged as unresolved, specific trigger for revisiting it).

The Correct Prompt

Convert this meeting transcript or notes into a structured meeting summary:

[Paste transcript, audio transcription, or rough notes]

Meeting type: [decision-making / status update / brainstorm / kickoff / retrospective]
Attendees and their roles: [list]

Output structure:
**Decisions made** (only things that were explicitly agreed -- not discussed): 
- Decision: [what was decided]
- Owner: [who owns it]
- By when: [deadline if stated]

**Action items**:
- Task: [specific task]
- Owner: [name]
- Due: [date or trigger]

**Topics discussed but not decided** (acknowledge without implying a decision was made):
- [topic] -- Status: [pending input from X / revisited at next meeting / no action needed]

**Parking lot** (topics raised but explicitly deferred):
- [topic] -- Revisit trigger: [what would bring this back]

**Not covered** (if any agenda items weren't reached): [list]

One rule: if something feels like it was decided but no one explicitly said "we're deciding this," flag it as [DECISION UNCLEAR] rather than writing it as a decision. False clarity is worse than acknowledged ambiguity.

What this does: The

[DECISION UNCLEAR]

Results and What Changed

After switching to this structured template, the project manager's meeting summary writing time dropped to 8-10 minutes per meeting -- she was formatting structured notes, not writing narrative prose. More importantly, the disputed-summary problem almost entirely disappeared: when an attendee read "Decision: [X] -- Owner: [Name] -- By: [Date]," there was almost nothing to misinterpret.

The [DECISION UNCLEAR] flags turned out to be more valuable than expected. About 30% of flagged items were resolved by a quick Slack message to the most senior person in the room. The other 70% revealed that the group had actually not made a decision and needed to -- catching that upstream rather than in the next meeting's "what did we decide" discussion saved more than the 15 minutes per meeting saved on writing.

⚡ Pro tip: Send the meeting summary within 30 minutes of the meeting ending, not 24 hours later. Summary disputes correlate strongly with elapsed time -- people's memories of what was decided solidify into their preferred interpretation the longer a summary takes to arrive. A structured summary sent quickly doesn't allow that solidification time.

How to Apply This to Your Situation

For recurring meetings (weekly standups, sprint reviews, one-on-ones), build a meeting-type-specific version of this template rather than using the generic version:

This is a weekly sprint review for an engineering team. Recurring structure:
- What shipped (with any quality notes)
- What didn't ship (with one-sentence reason and carry-forward plan)
- Blockers raised (with owner for resolution)
- Velocity note: [on track / ahead / behind] with one-line justification

Here are this week's notes: [paste]

What this does: Recurring meetings have recurring structures -- encoding the structure directly into the prompt means every week's summary is immediately comparable to last week's without formatting variation, which matters for standup-style meetings where trend-spotting across weeks is the actual point.

Three Real Scenarios

A product manager at a remote-first company used the [DECISION UNCLEAR] flag to fix a specific cultural problem: because the team never shared a physical space, ambiguous decisions had no informal resolution mechanism -- no hallway conversation to clarify what was actually decided. The flag created a lightweight async mechanism to resolve that ambiguity within hours rather than letting it harden into conflicting implementations.

An executive assistant supporting three C-level leaders used the meeting-type-specific template approach to build a different summary structure for each recurring meeting type: board updates (decisions only, no discussion narrative), leadership team (decisions plus owner assignments), and client calls (client actions versus internal actions, clearly separated). Each format was calibrated to what that audience needed from the summary, rather than one generic format applied to everything.

A project team using async communication found that the prompt's "not covered" section was unexpectedly valuable: for long meetings that ran out of time, explicitly documenting which agenda items weren't reached -- rather than implicitly expecting people to remember -- reduced the number of "wait, did we decide on X?" messages in the days following the meeting.

A Decision Log Prompt for Long-Running Projects

Here are the meeting summaries from the last [N] weeks on [project]: [paste or describe]

Extract just the decisions -- all of them, in chronological order. For each:
- What was decided
- Who made the call (or that it was a group decision)
- Whether it's been revisited or superseded since

This is a project decision log, not a meeting summary. Format it so someone new to the project could read it and understand what's been committed to, in what order, and by whom.

What this does: A decision log is structurally different from a meeting summary -- it's a project artifact rather than a meeting record, and it serves a different purpose: giving anyone joining the project a clear view of committed direction without reading through weeks of meeting notes. Building it from existing summaries rather than from scratch is where this prompt adds the most leverage.

Next Steps

A claude prompt template for meeting summaries that your whole team uses consistently produces a meeting record that's queryable, comparable, and trusted -- which is the actual value of meeting documentation. Storing the calibrated version in PromptABCD makes it available to everyone who takes meeting notes, not just the person who built the template.

The decision log prompt -- built from accumulated meeting summaries -- is worth running at the start of any project review, onboarding session, or audit. The single most common cause of repeated decisions is that no one can remember what was decided before, when, and why. A searchable decision log removes that bottleneck entirely. Building it from existing summaries using the prompt above takes about fifteen minutes and produces a document that would have taken hours to write from memory -- and would have been less accurate, because memory of what was decided tends to drift toward the current preferred interpretation rather than what was actually committed to at the time. For teams doing post-mortems on projects that went wrong, the decision log is almost always the most valuable artifact in the room -- it shows exactly where the decision that caused the problem was made, who owned it, and whether it was ever actually flagged as unclear at the time. That specificity turns a post-mortem from a blame conversation into a process conversation, which is where the actual improvement comes from.