Meeting Summary Prompts: Wall of Text vs Decision-Ready

A manufacturing plant runs a 45-minute production safety meeting every morning at 6:15. The plant manager, the EHS lead, and three line supervisors walk through a near-miss on Line 3, a PPE compliance gap, and a ventilation issue at the forklift charging station. Someone records it. Someone else asks ChatGPT to summarize the transcript, and forty-five minutes of decisions arrive back as six paragraphs of prose with no names, no dates, and no way to tell what was decided versus what was merely discussed.

By the next morning the meeting repeats the same three topics because nobody could act on the summary. The transcript was never the problem. The instruction “summarize this” was.

The Symptom: A Summary That Reads Fine and Does Nothing

A wall-of-text summary is not wrong; it is unusable. It restates the conversation in the order it happened, which is the least useful order for someone who needs to act. A supervisor scanning for their own action items has to read the whole thing and infer who owns what. Most people give up and ask someone who was in the room.

Decision-ready summaries invert the order. First the decisions, then the owners and dates, then the open questions, and only then the narrative context, if it is included at all.

Wall-of-Text Prompt vs Decision-Ready Prompt

Both prompts receive the same transcript. One asks for prose; the other asks for a structured record with fields that map to action.

Summarize this meeting transcript. Here is the transcript:

{{pasted transcript}}

Give me a clear summary of what was discussed.

You are the meeting secretary for a daily production safety
meeting at a manufacturing plant. Read the transcript and produce
a decision-ready record. Do not add any fact that is not in the
transcript; if a field is missing, write "Not stated."

Transcript:
{{pasted transcript}}

Output exactly these sections:

1. Decisions made (numbered). State the decision, who made it,
   and the deadline if one was given.
2. Action items as a table with columns: Owner, Action, Due date,
   Status. One row per item. Use roles as owners (Plant Manager,
   EHS Lead, Line 3 Supervisor), never invent personal names.
3. Safety issues raised (numbered), each with its line or area
   and whether it was resolved, deferred, or escalated.
4. Open questions (numbered) - things discussed but NOT decided.
5. Disagreements or dissent, with who held which position.
6. Next meeting date and the three items that must be on it.

Rules: bullet form only, no filler sentences, no praise or
commentary. Flag anything ambiguous with [CONFIRM] instead of
guessing.

The first prompt invites prose because “give me a clear summary” has no shape. The second prompt defines the output schema before the model reads a word of the transcript, so the transcript gets mined for specific fields instead of narrated.

Why the Structured Version Gets Used

• Decisions come first. The most valuable line in any meeting is what got decided. Leading with it lets a reader stop after section one if that is all they need.
• Owners and dates are forced. The table schema demands a name and a due date for every action. When neither exists, the model writes “Not stated” and the gap becomes visible.
• Discussion is separated from decision. Sections four and five capture the debate that did not resolve, so nothing is silently dropped or mistaken for a decision.
• Ambiguity is flagged, not smoothed. The [CONFIRM] rule stops the model from inventing a plausible owner to keep the summary tidy.
• It feeds the next meeting. Section six turns the summary into an agenda, which is how a recurring meeting stops repeating itself.

Applied to the Line 3 near-miss, the output might open with “Decision: install a new guard rail on Line 3 press by Friday, owner Plant Manager.” The raw transcript buried that sentence in the middle of a fifteen-minute discussion. The structured prompt pulls it to the top where it drives action.

Fields That Belong in Every Meeting Summary

Those six fields travel well across meeting types. A standup keeps decisions, owners, and blockers. A client call keeps decisions, open questions, and next steps. The schema changes; the principle does not. If your team already routes meeting output through a summarization workflow, this schema is what makes the output shareable without a follow-up call.

Adapt It to Your Own Meeting

The prompt above is specific to a safety meeting, but the skeleton is generic. Swap the fields for the ones your meeting actually produces.

You are the meeting secretary for {{meeting type}} at {{org}}.
Produce a decision-ready record. Use only facts in the transcript;
write "Not stated" when a field is missing.

Transcript:
{{pasted transcript}}

Output:
1. Decisions (numbered): decision, decider, deadline.
2. Action items table with columns: Owner, Action, Due, Status.
3. {{domain issues}} raised, with resolution state.
4. Open questions (discussed, not decided).
5. Dissent, with positions.
6. Next meeting date and its three agenda items.

Rules: bullets only, no filler, flag ambiguity as [CONFIRM].

Two habits make it stick. First, paste the transcript, not your notes; notes already contain your interpretation, and the model will summarize your bias back to you. Second, run a quick check for anything marked [CONFIRM] before you send the summary out, because that tag marks exactly where a human decision is still needed. Adjust the tone and length settings if your summaries come back too terse or too padded for the audience.

Sources & Notes

The summary schema here reflects common meeting-minutes practice and prompt behavior observed with GPT-4-class models in 2024–2025. The plant and its safety incidents are illustrative; no real facility is described. Structured summaries reduce follow-up questions but do not replace human sign-off on safety decisions. Internal references: Meeting Notes Summary Prompt, Meeting Summary Prompt Settings, Productivity Prompts List.