To turn meeting notes into action items with AI, ask for a structured extraction instead of a summary: a table with the task, a named owner, a due date and the exact quote each item came from, plus separate lists for decisions and open questions. Tell the model to write “No owner” or “No date” when the notes do not say, and give it the attendee list so it can match names correctly. Then send the table out in a second, separate prompt that drafts the follow-up message.
This guide gives the extraction prompt, explains each line, and then covers the parts that usually go wrong: messy auto-transcripts, vague commitments like “I’ll look into it”, recurring meetings where items carry over, and the review step before anything is sent.
Why a meeting summary is not an action list
A meeting summary describes what was talked about; an action list records who promised to do what by when. The two need different prompts. Ask “summarize this meeting” and you get a tidy narrative in which commitments are mixed in with discussion, often softened (“the team discussed improving the onboarding flow”) so that nobody is clearly responsible for anything.
Three things make a usable action item: a specific task, one owner, and a date or trigger. Meetings rarely state all three cleanly. People say “we should”, “someone needs to”, “let’s aim for next week”. The job of the prompt is to pull out every commitment, keep the gaps visible, and resist filling them with plausible guesses.
The extraction prompt
The prompt below works on handwritten notes typed up afterwards, shared-doc notes and full transcripts. Paste the notes first and the instructions after them; for long transcripts, placing instructions after the material tends to work better, as covered in the guide to summarizing long documents.
<meeting>
Title: [meeting name]
Date: [YYYY-MM-DD]
Attendees: [Full Name (role/team), Full Name (role/team), ...]
<notes>
[paste notes or transcript]
</notes>
</meeting>
Extract the outcomes of this meeting into three sections.
## Decisions
A numbered list. Each decision: what was decided, in one sentence, followed by the supporting quote in quotation marks. Mark a decision "TENTATIVE" if anyone raised an unresolved objection or said it depends on something.
## Action items
A table with columns:
# | Task | Owner | Due | Confidence | Source quote
- Task: start with a verb and be specific enough that someone who missed the meeting knows what "done" looks like.
- Owner: one person from the attendee list. If several people were mentioned, pick the one who said they would do it and list others in the task text. If no one took it, write "No owner".
- Due: a date in YYYY-MM-DD if one was said or clearly implied ("by Friday" = the Friday after the meeting date). Otherwise write "No date".
- Confidence: "Explicit" if someone clearly committed ("I'll send it tomorrow"); "Implied" for soft commitments ("I can take a look", "let me check").
- Source quote: the exact words from the notes, so the item can be verified.
## Open questions
Questions raised that were not answered, with who raised them and who might answer.
Rules:
- Use only the notes. Do not add tasks that "would make sense".
- Never invent an owner or date. Gaps are useful information.
- If a speaker label is missing or ambiguous in the transcript, write "Speaker unclear" in the Owner column instead of guessing.
- Ignore tasks that were mentioned and then explicitly dropped, but list them at the end under "Dropped" with the quote.Why each part is there
- Meeting date. Without it, “by Friday” cannot become a date. With it, the model can resolve relative deadlines, and you can check the arithmetic.
- Attendee list with roles. Transcripts often show first names, nicknames or misspellings (“Pria” for “Priya”). The list lets the model normalize names, and the roles help it assign items like “billing will check” to the right person.
- Three separate sections. Decisions need to be communicated, action items need to be tracked, open questions need an answer. Mixing them is how an unanswered question gets mistaken for a decision.
- “Task starts with a verb”. “Pricing page” is a topic; “Draft new pricing page copy for review” is a task.
- Confidence column. Informal phrases like “I’ll take a look at that” are often real commitments that get lost. Capturing them as “Implied” keeps them on the list while signalling that the owner should confirm.
- Source quote. It makes review fast and catches the most common error: an item that sounds right but nobody actually agreed to. For more on quote-backed outputs, see making Claude cite the exact sentence behind every claim.
- “Dropped” list. Meetings often reverse themselves. Recording what was dropped prevents a stale idea from resurfacing as a task.
Before and after: a short example
The following excerpt is invented for illustration. The meeting date is 2026-10-19 (a Monday); attendees are Priya Shah (product), Tom Becker (engineering) and Ana Lima (support).
Priya: So we're agreed the export fix goes out before the pricing change?
Tom: Yeah, export first. I'll have a build on staging by Wednesday.
Ana: Can someone write up the workaround for support in the meantime?
Tom: I can take a look at that, maybe.
Priya: We also need the new plan names from finance. Not sure who's chasing that.
Ana: Do we know if the old plan stays visible for existing customers?
Priya: Good question, I don't know yet.A plain summary of this would read something like “The team agreed to prioritize the export fix and discussed support documentation and plan naming.” Accurate, and useless for follow-up. The extraction prompt produces:
| # | Task | Owner | Due | Confidence | Source quote |
|---|---|---|---|---|---|
| 1 | Deploy export fix build to staging | Tom Becker | 2026-10-21 | Explicit | “I’ll have a build on staging by Wednesday.” |
| 2 | Write export workaround article for support | Tom Becker | No date | Implied | “I can take a look at that, maybe.” |
| 3 | Get new plan names from finance | No owner | No date | Explicit | “We also need the new plan names from finance.” |
Plus one decision (“Export fix ships before the pricing change”) and one open question (“Does the old plan stay visible for existing customers?”, raised by Ana, owner unknown). The gaps are now obvious: item 3 needs an owner, item 2 needs Tom to confirm, and the open question needs to go to whoever owns pricing.
Handling messy auto-generated transcripts
Auto-generated transcripts are the most common input today, and they bring specific errors: misattributed speakers, misheard names and product terms, and cross-talk merged into one line. Add the following block to the extraction prompt when working from a raw transcript.
This is an automatic transcript and may contain errors.
- Glossary of names and terms that are often misheard: [e.g. "Kubernetes" (not "Cooper Netties"), "Priya" (not "Pria"), "Acme Corp"].
- If an item depends on a word that looks misheard, include it with "[possible transcription error: ...]" in the task text.
- If the same person appears under two labels (e.g. "Speaker 2" and "Tom"), treat them as one only if the context makes it clear; otherwise write "Speaker unclear".
- Ignore filler, false starts and repeated phrases.The glossary is the cheapest fix available. Transcription models struggle most with internal jargon, product names and non-English names, and a short list of correct spellings usually resolves most of it.
What built-in meeting AI already does
Both major meeting platforms now generate notes with action items, and it is worth knowing what they cover before building your own prompt workflow.
| Platform feature | What it produces | Requirements and limits (per official help pages) |
|---|---|---|
| Google Meet “Take notes for me” | A Google Doc with quick notes and full notes, including summary, decisions, next steps and details sections that can be toggled. | Needs an eligible Workspace edition or Google AI plan; one supported language per meeting; recommended for meetings of 15 minutes or more; Google warns notes may be incomplete or inaccurate. |
| Microsoft Teams intelligent recap | AI notes and suggested follow-up tasks in the meeting recap, shareable as an Outlook email draft. | Needs Teams Premium or a Microsoft Copilot license; the meeting must be transcribed and last at least five minutes; Microsoft warns content may be inaccurate or incomplete. |
Details are from Google’s Take notes for me help page and Microsoft’s Recap in Microsoft Teams page; both change often, so check them for your edition. A custom prompt still adds value on top of these tools when you need source quotes, explicit “No owner” gaps, your own glossary, a specific output format for your task tracker, or processing of notes from meetings that were not recorded on those platforms. A practical pattern is to take the platform’s transcript and run your own extraction prompt over it.
Second prompt: the follow-up message
Drafting the follow-up in a separate step, from the reviewed table, gives cleaner results than asking for extraction and email in one prompt. The extraction stays focused on accuracy, and the email works only from items a human has already checked. This is a small example of prompt chaining.
Here is the reviewed outcome table from [meeting name] on [date]:
[paste decisions, action items, open questions]
Write a follow-up message for [email / Slack channel] to all attendees.
- Subject or first line: meeting name, date, and the number of action items.
- Decisions first, one line each.
- Action items grouped by owner, with due dates, in a list.
- Items with "No owner" or "No date" in a separate "Needs an owner or date" section, phrased as a direct ask (e.g. "Who can chase finance for the plan names?").
- Items marked "Implied": ask the owner to confirm in one line.
- Open questions at the end, each with a suggested person to answer it.
- Under 200 words. No recap of the discussion. No pleasantries beyond one opening line.The “Needs an owner” section is the point of the whole exercise. Turning ownerless items into direct questions to the group is what gets them picked up. If the team runs updates asynchronously, the same table can feed weekly status reports.
Recurring meetings: carrying items forward
For weekly or sprint meetings, the most useful addition is a status check on last meeting’s items. Paste the previous action table above the new notes and add this block.
<previous_actions>
[paste last meeting's action table]
</previous_actions>
Before extracting new items, give each previous action a status based only on today's notes:
Done (quote) / In progress (quote) / Not mentioned / Blocked (quote and reason) / Dropped (quote).
Then extract new items as usual. If a new item duplicates a previous one, update the previous item instead of creating a new row.“Not mentioned” is a useful status in its own right: an item that goes unmentioned for two or three meetings is effectively abandoned, and the list makes that visible. Pairing this with a good agenda helps; the prompts for meeting agendas include a slot for reviewing open actions at the start.
Review checklist before you send anything
An AI-extracted action list should be reviewed by someone who attended the meeting, ideally the organizer, before it goes out. The review takes a couple of minutes with the source-quote column.
- Check every owner against the quote. Assigning a task to the wrong person is the most damaging error, because it publicly commits someone to work they did not agree to.
- Check resolved dates. Confirm that “next week” and “by Friday” were converted using the meeting date, not today’s date.
- Look for missing items. Skim the notes for “I’ll”, “we need”, “can you”, “let’s”. If you find a commitment not in the table, add it and consider whether your prompt needs a rule for that phrasing.
- Confirm tentative decisions are labeled. A tentative decision sent as final causes more trouble than a missed one.
- Remove anything sensitive. Meeting notes can include HR, salary or customer details that should not go to the whole attendee list or into a tracker visible to others.
Exporting to a task tracker
If items go into Jira, Asana, Linear, Trello or a spreadsheet, ask for the reviewed table in a format the tool can import, usually CSV with the tool’s own column names. Keep the source quote in the description field so the context travels with the task. For automated pipelines that call an API, request JSON with a fixed schema and validate it before creating tasks; never let an unreviewed extraction create or assign tickets automatically, for the same reason the review checklist puts owners first.
Convert the reviewed action items to CSV with these exact headers:
Summary,Assignee,Due date,Description,Labels
- Summary = Task
- Assignee = Owner's email from this list: [name: email, ...]; leave blank for "No owner"
- Due date = YYYY-MM-DD or blank
- Description = "From [meeting name] on [date]. Source: " + source quote
- Labels = meeting-actions
Output only the CSV, with values containing commas wrapped in double quotes.
