Turn a Meeting Transcript Into Decisions and Actions
"Summarize this transcript" turns suggestions into decisions, invents deadlines, and drops owners. Here's how to extract decisions, action items, owners, deadlines, and open questions instead — each with evidence and a needs_review flag, and "not stated" for what's missing.
Build a Meeting Extraction PromptWhen "summarize this" loses the decisions
The meeting ends, you paste the transcript in, and type "summarize this." What comes back reads well — a tidy paragraph or two of what the meeting was about. Then you try to use it, and the parts you actually needed aren't there or aren't right: a suggestion someone floated is written up as a decision, a "we should probably…" has hardened into an assigned task, a deadline you don't remember agreeing to has appeared, and the one question nobody resolved is gone. The summary captured the conversation. It did not capture the commitments — and the commitments are the reason anyone will open it next week.
The fix is to stop asking for a summary and start asking for an extraction. A summary compresses the transcript for reading; what you need is a structured list you can act on and check — decisions that were actually made, action items with an owner and a due date, the questions still open, and the things that were mentioned but never decided, each traceable back to what was said. This guide is how to turn a meeting transcript into action items and decisions without that drift. NewPrompt builds that extraction prompt for you — the Extraction Prompt Generator writes the fields, the rules, and the missing-data behavior — and it is honest about the boundary: it doesn't record your call, transcribe audio, join the meeting, or create tasks in your tracker. You paste the transcript into your own AI tool, and what comes back is a candidate extraction you check against the transcript, not a verified account of who agreed to what. The AI was not in the room.
Why a summary is the wrong shape for outcomes
A summary and an outcome list are built for different jobs. A summary answers "what was this meeting about?" — it smooths the messy back-and-forth into readable prose, and that smoothing is exactly what erases the distinctions that matter afterward. Here is what gets lost when discussion is compressed into a paragraph:
- Discussion blurs into decision. "We talked about delaying the beta" and "we decided to delay the beta" read almost the same in a summary — and only one of them is true.
- Commitments phrased as talk get missed. The real action item is often a line like "I'll check with QA by Friday," not a labeled task — and a summary that isn't looking for it drops it.
- Owners and deadlines get invented to fill the shape. Asked for a clean recap, the model supplies a plausible owner or date the transcript never contained, because a tidy sentence wants one.
- Disagreement collapses into one conclusion. Two people who didn't actually agree become "the team decided," and the unresolved tension disappears.
- Open questions vanish. The thing nobody answered has no natural home in a paragraph, so it quietly drops off — and it is often the most important item.
- "Mentioned" becomes "agreed." A topic that was raised and left hanging gets written up as settled, because prose doesn't separate raised from resolved unless you make it.
Step 1: Ask for an extraction with named sections, not a recap
Give the output a shape that forces the distinctions a paragraph erases. Instead of "summarize," ask the model to sort the transcript into named sections: decisions made, action items, open questions, risks or blockers, follow-ups, and — the one people forget — mentioned but not decided. That last section is where suggestions and half-agreements go, so they stop leaking into the decisions list. The sections do the work: once "decisions made" and "mentioned but not decided" are separate buckets, the model has to choose which one a given line belongs in, and choosing is what surfaces the difference between talk and a commitment.
The Extraction Prompt Generator is built for exactly this move — pulling defined fields out of unstructured text with field definitions, extraction rules, a missing-data behavior, and an ambiguity policy, rather than compressing the text into prose. The Extract Action Items From Meeting Notes resource is that setup already shaped for meetings: its decisions field is defined as "decisions actually made — not topics discussed," and its reading guidance warns that commitments hide in sentences like "Sara will send the deck." Both hand you a prompt you run yourself; NewPrompt writes the structure, and your own AI does the reading.
Step 2: Draw the line between a decision and a suggestion
The section headers only help if the model knows what counts as a decision, so define it in the prompt. A decision is something the group explicitly agreed, decided, or confirmed — not a suggestion, not an option someone raised, and not a point people were still arguing over. Tell the model that a topic discussed but not resolved belongs in "mentioned but not decided," and that a disagreement is never written as a decision. Then require an evidence phrase for every decision: the sentence from the transcript that shows it was actually settled. The evidence requirement is the guardrail — if the model can't quote a line where the decision was made, that is the signal it wasn't one, and you see the gap instead of trusting a confident claim.
This is the distinction the whole extraction turns on, and it is why "the last word on a topic usually reflects the decision" is a useful reading rule for spoken transcripts, where people circle a point before landing it. But usually is not always — sometimes the last word is a tangent, or the topic was left open on purpose. That is exactly why the evidence phrase matters: it lets you check the model's call against the sentence it rested on, rather than taking the label at face value.
Step 3: Give every action item an owner, a date, and a status
An action item with no owner and no date is not an action item — it is a wish. So structure each one as fields rather than a sentence: the task (what will be done), the owner (who committed to it), the due date (when), any dependency (what it is waiting on), the evidence (the line that shows the commitment), and a status. The status field is what keeps the list honest: mark an item "confirmed" when someone clearly took it on, "implied" when the transcript points at a task but nobody explicitly owned it, and "needs_review" when it is a real follow-up that still has to be assigned before it can move. That three-way split blocks the two opposite failures at once — dropping a commitment that was phrased conversationally, and inventing a crisp assignment that was never actually made.
The reason to demand a status rather than a clean yes/no is that meetings are full of half-commitments, and forcing them into "assigned" or "not assigned" is where the fabrication happens. A model told to produce a neat task list will round "someone should look at pricing" up to "Pat will review pricing by Friday." A model told to mark that "needs_review, owner not stated" gives you the truth: a task exists, and you still have to assign it. The visible-gap version is the more useful one precisely because it tells you where the work isn't done yet.
Step 4: When the owner or date is missing, leave it missing
The single most important instruction in a meeting extraction is what to do when a field isn't in the transcript — because the model's default is to fill it. Tell it plainly: if the owner isn't stated, write "not stated"; if there is no date, write "not stated"; never guess a value from outside the transcript. A visible "not stated" in an owner column is something a reviewer catches and resolves; a plausible invented name is something they trust and never check. The Missing Data in AI Extraction resource lays out the choices here — leave it empty, write "unknown" or "not stated," or skip the field — around the one rule that survives all of them: never invent or guess a value for a missing field.
Speaker ambiguity is the same problem wearing a different hat. Transcripts are full of "we," "the team," and "someone should," and none of those names an owner. Tell the model not to resolve them — "we'll handle it" stays unassigned, not quietly pinned on whoever spoke last. And if the transcript carries no speaker labels at all, it shouldn't invent them: an action with an unknown owner is honest, while an action credited to the wrong person is worse than one credited to no one. The whole point is to make the gaps visible so you can close them, not to paper over them with confident guesses.
Step 5: Check it against the transcript, and keep task entry yours
The output looks like a finished record, which is exactly why you can't treat it as one. Read the high-impact items back against the transcript first — the decisions with consequences and the action items that carry an owner and a deadline are the ones worth the thirty seconds, because they are the ones people will act on. For each, the evidence phrase makes the check fast: does the quoted line actually support the decision or the commitment as written? A good last pass is to ask, "what here could be misleading?" — it catches the suggestion promoted to a decision and the deadline that reads firmer in the summary than it sounded in the room.
Then remember what the list is and isn't. It is a candidate extraction — the model's best reading of the words, not a verified account of what the group intended or agreed to. It can't tell a genuine commitment from a polite "sure, I'll look into it," and it can't know the shared context that made a vague line unambiguous to the people who were there. So on anything that matters, confirm the decisions and owners with the people who were present, and enter the tasks into your own tracker yourself — NewPrompt structures the extraction, but it doesn't create tasks, assign owners, or set reminders, and the record becomes real only when a person stands behind it.
Common mistakes
The habits that turn a meeting transcript into a confidently wrong record:
- Asking for a summary when you need outcomes. "Summarize this" optimizes for readable prose, not for decisions and owners — ask for a sorted extraction instead.
- Letting discussion count as a decision. Without a defined line between agreed and merely discussed, debate ends up in the decisions list — require an evidence phrase for each decision.
- Accepting owners and dates with no source. A plausible owner is easy to invent and easy to trust; make missing fields say "not stated" so the gaps stay visible.
- Forcing half-commitments into assigned tasks. "Someone should look at this" is not "Pat will do it by Friday" — a needs_review status keeps the unassigned honest.
- Dropping the open questions. The thing nobody resolved has no home in a summary; give it a section so it survives the meeting.
- Treating the output as a task list. It is a candidate extraction to review against the transcript, not a verified list to paste straight into your tracker.
A worked example: a short transcript, summarized wrong then extracted
Watch five lines get summarized into something confidently wrong, then boxed into what the transcript actually supports.
"Summarize this" promotes a suggestion to a decision and invents an owner; a sorted extraction keeps decided apart from discussed, marks the unowned action needs_review, and quotes the evidence for each lineTRANSCRIPT EXCERPT:
Maya: We should probably delay the beta until the onboarding bug is fixed.
Jon: I agree on fixing onboarding first, but I won't commit to a new beta
date today.
Priya: I'll check the onboarding bug with QA and post an update by Friday.
Maya: Good. Let's keep the current beta date tentative until Priya reports back.
Jon: Also, the pricing page copy needs legal review before launch.
THE "SUMMARIZE THIS" RESULT (reads fine, quietly wrong):
"The team decided to delay the beta, Priya will fix onboarding by Friday,
and legal will review the pricing page before launch."
what it got wrong:
- the beta delay was NOT decided -- the date was kept tentative
- Priya committed to CHECK with QA and post an update, not to FIX the bug
- "legal will review" has no owner anywhere in the transcript
- a suggestion ("we should delay") was written up as a decision
AN EXTRACTION PROMPT (pull only what the transcript supports):
Extract only what the transcript states. Sort it into:
decisions_made | action_items | open_questions | mentioned_but_not_decided
Rules:
- A decision is something explicitly agreed or confirmed -- not a
suggestion, an option, or an unresolved debate.
- Do not invent owners or deadlines. If not stated, write "not stated".
- Mark an action that was implied but not clearly assigned as needs_review.
- Include the source sentence as evidence for each decision and action.
THE SHAPE YOU WANT BACK:
{
"decisions_made": [
{ "decision": "Fix the onboarding bug before moving the beta date.",
"evidence": "I agree on fixing onboarding first..." },
{ "decision": "Keep the current beta date tentative until Priya reports back.",
"evidence": "Let's keep the current beta date tentative until Priya reports back." }
],
"action_items": [
{ "task": "Check the onboarding bug with QA and post an update.",
"owner": "Priya", "due_date": "Friday", "status": "confirmed",
"evidence": "I'll check the onboarding bug with QA and post an update by Friday." },
{ "task": "Get legal review for the pricing page copy before launch.",
"owner": "not stated", "due_date": "before launch", "status": "needs_review",
"evidence": "the pricing page copy needs legal review before launch" }
],
"mentioned_but_not_decided": [ "Delaying the beta until onboarding is fixed." ],
"open_questions": [ "Will the beta date move after Priya's update?",
"Who owns the legal review?" ]
}
NEXT: check each decision and owner against the transcript yourself, then enter
the confirmed tasks into your own tracker -- assigning any owner still marked
"not stated" as you go.Where this fits in NewPrompt
Pulling structure out of unstructured text is a whole family of jobs, and this is the meeting-shaped one. The Extraction Prompt Generator builds the prompt — fields, extraction rules, missing-data behavior, ambiguity policy. The Extract Action Items From Meeting Notes resource is that generator already tuned for meetings, and the Missing Data in AI Extraction resource is where the "not stated" behavior comes from. Each gives you a prompt you run in your own AI tool; NewPrompt writes the structure, and the reading happens on your side, on a transcript you paste in.
Two neighbors are worth telling apart. Extracting fields from a document — an invoice total, a contract date, a name — is the same tool on a tidier source; the meeting version is harder because the value you want, whether something was actually decided, isn't a phrase sitting in the text but a judgment about what the words mean, which is why the decided-versus-discussed line and the evidence phrase carry so much of the weight. And when your goal genuinely is a readable narrative record — board minutes, a formal recap with commitments preserved in their exact wording — that is a summary, not an extraction, and the Summarize Meeting Transcripts resource is the faithful version of it. Extraction gives you reviewable fields to act on; a record gives you prose to file. Pick by what you will do with it next.
A meeting's worth isn't in how well the conversation reads afterward — it is in what leaves the room as a commitment someone can act on. The transcript is the raw evidence of the talk; the decisions and the actions are the part that has to survive into next week, and they only survive if you pull them out on purpose, mark what is still open, and check the result against what was actually said. The model can draft that shortlist from the words in front of it, but only the people in the meeting know what was truly agreed — so the extraction is the starting point for the record, and you are the one who makes it true.