Meetings are expensive. An hour-long meeting with six people costs six hours of collective time. And yet, most of that value evaporates because the notes are incomplete, the action items are vague, and nobody remembers who agreed to what by the next day.
AI is exceptionally good at processing raw meeting notes — the messy, half-formed kind you actually take during meetings — and turning them into structured outputs. But "summarize these meeting notes" produces a generic recap that misses the important decisions and commitments.
These five patterns extract specific, actionable outputs from meeting notes. Each one serves a different purpose, and you'll often use two or three of them on the same set of notes.
Pattern 1: The Structured Summary
This pattern turns a wall of raw notes into a clean, scannable summary organized by topic — not chronologically, but by what matters.
Here are my raw notes from a meeting. They're messy and may be incomplete.
Meeting context:
- Purpose: [What the meeting was about]
- Attendees: [Who was there]
- Date: [When it happened]
Raw notes:
[Paste your notes here — even bullet fragments, shorthand, and incomplete thoughts are fine]
Organize these notes into a structured summary:
1. **Key decisions made**: What was agreed on. Be specific — "we decided to launch on April 20" not "we discussed the launch timeline."
2. **Discussion highlights**: The 3-5 most important points discussed, organized by topic (not chronologically)
3. **Open questions**: Things that were raised but not resolved
4. **Parking lot**: Topics that were mentioned but deferred to a future discussion
Format rules:
- Use bullet points throughout
- Keep each point to 1-2 sentences
- If something is ambiguous in my notes, flag it with [UNCLEAR] rather than guessing
- Total length: under 300 wordsWhy it works: Organizing by decision/discussion/question instead of chronologically puts the most important information first. The [UNCLEAR] flag prevents the AI from fabricating details when your notes are ambiguous — which they almost always are. The "parking lot" captures important items that would otherwise be lost.
Example output snippet:
Key decisions:
- Launching the redesigned checkout flow on April 20 (Sarah owns implementation)
- Cutting the A/B test for the header — going with variant B based on last week's data
- Postponing the mobile optimization work to Q3 [UNCLEAR: was this all mobile work or just the checkout flow?]
>
Open questions:
- Do we need legal review before changing the refund policy copy?
- What's the budget ceiling for the paid acquisition test?
Pattern 2: The Action Item Extractor
This pattern does one thing and does it well: pull every commitment, task, and deliverable out of meeting notes and assign them clearly.
Extract all action items from these meeting notes.
Meeting context: [Brief description — e.g., "weekly product team sync, April 10"]
Raw notes:
[Paste your notes here]
For each action item, provide:
- **Task**: What needs to be done (specific and actionable — "finalize the Q2 roadmap" not "work on roadmap stuff")
- **Owner**: Who's responsible (if mentioned in notes; if not, mark as [UNASSIGNED])
- **Deadline**: When it's due (if mentioned; if not, mark as [NO DEADLINE SET])
- **Context**: One sentence on why this matters or what it's connected to
- **Dependencies**: Any blocker or prerequisite (if applicable)
Rules:
- Include explicit commitments ("I'll send that by Friday") AND implied ones ("we need someone to handle the vendor call")
- If a task is vague in the notes, make it as specific as you can. If you can't, flag it as [NEEDS CLARIFICATION]
- Sort by deadline (soonest first), then by unassigned items at the end
- Do not invent action items that aren't in the notesWhy it works: Separating explicit from implied commitments catches things people said they'd do and things that need doing but nobody claimed. The dependency field surfaces blockers before they become surprises. Sorting by deadline creates a natural priority order.
Example output snippet:
1. Task: Send the updated wireframes to the engineering team
Owner: Sarah
Deadline: Friday, April 12
Context: Engineering can't start the checkout redesign until they have final wireframes
Dependencies: Needs sign-off from David on the mobile layout
>
2. Task: Schedule a meeting with the legal team about refund policy changes
Owner: [UNASSIGNED]
Deadline: [NO DEADLINE SET]
Context: The new checkout flow includes updated refund language that may need legal review
Dependencies: None
Pattern 3: The Decision Log
When meetings produce important decisions, those decisions need to be documented — not just what was decided, but why, and what alternatives were considered. This pattern creates a permanent record.
Create a decision log from these meeting notes.
Meeting: [Name/purpose]
Date: [Date]
Attendees: [Who was present]
Raw notes:
[Paste your notes here]
For each decision made during the meeting, document:
1. **Decision**: What was decided (stated clearly and definitively)
2. **Rationale**: Why this option was chosen (the reasoning, not just "we agreed")
3. **Alternatives considered**: What other options were discussed and why they were rejected
4. **Impact**: What changes as a result of this decision (who's affected, what processes change)
5. **Revisit date**: When this decision should be reviewed, if applicable (e.g., "after the Q2 launch" or "if conversion drops below 3%")
Rules:
- Only include actual decisions — not things that are still being discussed
- If the rationale wasn't explicitly stated in the notes, write [RATIONALE NOT CAPTURED]
- If alternatives weren't discussed, write "No alternatives were raised in this meeting"
- Number each decision for easy referenceWhy it works: Decision logs prevent the "why did we do this?" problem that plagues every organization. Documenting alternatives that were rejected prevents rehashing the same debate in future meetings. The revisit date ensures decisions don't become permanent by default.
Example output snippet:
Decision #1: Use Stripe for payment processing instead of building a custom integration
>
Rationale: The engineering team estimated 6 weeks for a custom build vs. 1 week for Stripe integration. The cost difference doesn't justify the timeline delay given the Q2 launch target.
>
Alternatives considered:
- Custom integration with our bank's API — rejected due to timeline (6+ weeks) and maintenance burden
- PayPal — rejected due to higher transaction fees for our average order value
>
Impact: Engineering can start payment integration immediately. Finance needs to set up a Stripe account. Transaction fees will be 2.9% + $0.30 per transaction.
>
Revisit date: After processing the first $100K in transactions — evaluate if fee structure warrants renegotiation or switch.
Pattern 4: The Follow-Up Email Drafter
After certain meetings, you need to send a follow-up email that's polished enough to send to clients, executives, or external partners. This pattern turns raw notes into a ready-to-send email.
Draft a follow-up email based on these meeting notes.
Meeting context:
- Who I'm emailing: [Recipient name, role, and relationship — e.g., "client, VP of Marketing at Acme Corp"]
- Meeting type: [e.g., "project kickoff", "quarterly review", "sales discovery call"]
- My role: [Your position]
- Tone needed: [e.g., "professional and warm", "formal", "casual but competent"]
Raw notes:
[Paste your notes here]
Email structure:
1. Brief thank-you or reference to the meeting (1 sentence, not generic)
2. Summary of what we aligned on (3-5 bullet points)
3. Action items with owners and deadlines (formatted clearly)
4. Next steps or next meeting date
5. Professional closing
Requirements:
- Under 200 words
- The summary should only include things both parties agreed to — don't include my internal notes or one-sided observations
- Make action items crystal clear about who does what by when
- If any items need confirmation from the recipient, phrase them as questionsWhy it works: The instruction to only include mutually agreed items prevents accidentally sharing internal strategy or one-sided assumptions. Phrasing uncertain items as questions gives the recipient a natural way to correct misunderstandings. The 200-word limit keeps it respectful of the reader's time.
Example output snippet:
Hi Priya,
>
Thanks for the productive kickoff yesterday — especially the clarity on timeline priorities.
>
Here's what we aligned on:
- Project scope: Redesign of the customer portal, focusing on the dashboard and reporting modules
- Timeline: Design phase through May 15, development May 16 - June 30
- Weekly check-ins every Tuesday at 10am ET
>
Action items:
- Your team: Share access to the current analytics dashboard by Friday (we need this to audit the existing data flow)
- Our team: Deliver initial wireframes by April 25
- Open question: Can you confirm whether the SSO integration is in scope or a Phase 2 item?
>
Next meeting: Tuesday, April 15 at 10am ET.
Pattern 5: The Stakeholder Brief
Sometimes you attend a meeting on behalf of a broader group and need to report back. This pattern creates a concise brief tailored for people who weren't in the room.
Create a stakeholder brief from these meeting notes.
Meeting: [Name/purpose]
Who needs this brief: [Which stakeholders — e.g., "the executive team", "the engineering department", "the board"]
What they care about: [What information is most relevant to this audience]
Raw notes:
[Paste your notes here]
Write a brief that includes:
1. **One-line summary**: The single most important thing they need to know
2. **What was decided**: Decisions that affect the stakeholder group (skip internal decisions that don't impact them)
3. **What they need to do**: Any action required from their side
4. **What changed**: Anything different from the previous plan or expectation
5. **Timeline updates**: Any dates that were set, moved, or are at risk
Rules:
- Write for someone who has 60 seconds to read this
- Filter ruthlessly — only include information relevant to this specific audience
- Lead with changes and decisions, not discussion recaps
- Under 150 words
- Use bullet pointsWhy it works: The audience-specific filtering is the key differentiator. A meeting might discuss 20 things, but the engineering team only needs to know about three of them. The "what changed" section ensures stakeholders immediately see what's different from what they last knew, which is the information most likely to require their attention.
Example output snippet:
One-line summary: Launch date moved from April 20 to April 27 due to unresolved payment integration testing.
>
What was decided:
- QA team gets an extra week for payment flow testing
- Marketing collateral deadline remains April 18 (no change)
>
What you need to do:
- Update the launch announcement email with the new date
- Confirm the press release can be rescheduled with the PR agency by Wednesday
>
What changed: One-week delay to launch. All other milestones remain the same.
Quick Tips for Meeting Notes Prompts
- Paste raw notes, not polished ones. These patterns are designed to process messy input. Don't spend time cleaning up your notes before feeding them to the AI — that defeats the purpose.
- Include attendee names. The AI can only assign action items to people it knows were in the meeting.
- Specify the meeting type. A brainstorming session needs a different summary structure than a decision-making meeting or a status update.
- Run multiple patterns on the same notes. The structured summary, action items, and follow-up email serve different audiences and purposes. One set of notes, three outputs.
- Add "do not invent details." This is critical for meeting notes. If the AI can't determine something from your notes, you want it to flag the gap, not fill it with plausible-sounding fiction.
When to Use Templates vs. Write From Scratch
Use these patterns when:
- You have recurring meetings (weekly syncs, monthly reviews) where the output format should be consistent
- You need to produce multiple outputs from one meeting (summary + actions + email)
- You're processing notes from a meeting you attended but didn't run — the structure helps you organize someone else's agenda
Write from scratch when:
- The meeting was unusually sensitive and you need to carefully control what information appears in writing
- You have a transcript (from Otter, Fireflies, etc.) and want to use a prompt specifically designed for transcript processing rather than notes
- The meeting had a very specific output requirement that none of these patterns cover
For meetings you run regularly, SurePrompts' Template Builder lets you save meeting-specific prompt templates so your weekly standup notes and your quarterly board meeting notes each have their own optimized format.