Turning meeting notes into a presentation for a manager or decision-maker is not a matter of copying every sentence onto a slide. The useful deck shows what the meeting established, what still needs approval and what decision the next audience is being asked to make.
Start with the notes as evidence and write the decision request yourself. Then Presenti’s text-to-presentation workflow can help turn the selected material into a slide outline. This guide focuses on the six-slide decision story; for an operational action recap and copyable generation prompt, use the meeting-notes-to-slides AI example.
1. Find the decision inside the notes
Read the notes once without designing slides. Mark each sentence as a decision, an observation, an open question, an action or background. This prevents a long discussion about options from becoming a deck that never asks for a choice.
For example, a product team may have discussed a self-service reporting pilot. The notes might contain a proposed audience, two unresolved data questions, an owner for a prototype and a request for approval to test it. The first slide should ask for the bounded pilot decision, not repeat the meeting title.
| Note type | What to extract | Slide treatment |
|---|---|---|
| Decision | What was approved, rejected or requested | Use as the headline or decision slide |
| Observation | What someone saw, measured or reported | Keep the source and scope visible |
| Open question | What still needs evidence or an owner | Show it as a risk or next investigation |
| Action | Who will do what, and by when if known | Turn it into an accountable next step |
2. Remove discussion noise without removing conditions
Meeting notes contain repetitions, polite framing and partial sentences. Remove those surface details, but keep conditions that change the meaning. “Proceed if security approves the data source” is not equivalent to “Proceed.” “The estimate is pending” is not equivalent to a cost.
Keep a short evidence ledger while editing. For each number, record the unit, time window, denominator and source sentence. For each recommendation, record the assumption that makes it reasonable. If a note does not provide the information, label the gap instead of filling it with a plausible detail.
Before drafting, mark the intended audience beside each source item. A manager may need the unresolved approval and budget; a delivery team needs the assigned work; an external audience should receive only material approved for sharing. Leave private remarks, names and commercially sensitive details out of the presentation unless they serve the task and may be shared.
3. Build a six-slide story from the same source
A compact meeting-summary deck can use this sequence:
- Decision requested: state the choice and the scope of approval.
- What prompted the discussion: show the observed problem and its boundaries.
- What the team learned: separate evidence from interpretations.
- Options and trade-offs: compare only choices the group can actually approve.
- Open risks: list unresolved questions, dependencies and owners.
- Next step: state the action, owner and review point.
Use one source example across the sequence. If the notes say that 18 of 24 pilot users completed a task and that 20 of 80 requests lacked a required field, do not combine the numbers into a single “adoption rate.” They describe different units. A clean deck makes that distinction easy to see.
A worked example: from the raw note to six slide headlines
Here is a fictional extract from a product-team meeting. Use it as the source for the deck, rather than adding a different example to each slide.
In an internal test, 18 of 24 participants completed the reporting task. Separately, 20 of 80 support requests lacked a required field. Mina will prepare a prototype. The team discussed a two-week pilot, but security has not approved the data source and no budget has been agreed. The next meeting is Monday; no pilot start date was decided.
The six slides can now say something specific:
- Decision requested: should the team prepare a two-week pilot for approval after security review? The notes record a discussion, not an approved pilot. Present this as the next decision, not an existing commitment.
- Reason for discussion: 20 of 80 support requests lacked a required field. Show that count and its unit. The notes do not quantify the extra work it caused.
- What the test showed: 18 of 24 participants completed the reporting task. State that this was an internal test, not evidence of wider customer adoption.
- Options: continue the current process or run the limited pilot after approval. Compare the learning each option provides; leave cost as unresolved.
- Dependency: security approval and the budget are still open. Do not mark either as complete or assign an owner absent from the notes.
- Next action: Mina is to prepare the prototype. The next discussion is Monday, but the notes do not give Mina a due date or establish a launch date.
For a different audience, change the emphasis rather than the facts. An executive version may put the pilot decision first; a delivery-team version may lead with the prototype and dependencies. Both should preserve the same unresolved budget and approval conditions.
| Decision-brief element | Use from the example | Keep unresolved |
|---|---|---|
| Request | Consider a bounded two-week pilot after the security review | Who has final approval and when it will be given |
| Evidence | 18 of 24 participants completed the task; 20 of 80 requests lacked a field | Whether either sample represents the wider population |
| Resource question | A prototype has an assigned owner | Cost, budget approval and prototype due date |
| Next conversation | The next meeting is Monday | Whether it is an approval meeting or a progress review |
4. Keep speaker language aligned with the slide
Write a one-sentence spoken explanation for every slide. It should add context, not introduce a new conclusion. If the slide says “pilot approval depends on a security review,” the spoken explanation should not say “the pilot is ready.”
Put detailed discussion history in an appendix or linked notes, not in tiny text on the main slide. The audience needs to see the decision path first; people who need the full record can inspect the source notes and appendix. If the next audience needs only the current state, owner and request, use a one-slide status update instead of repeating the full decision brief.
5. Give the slide draft a controlled input
Use the six-slide story only after the meeting owner has resolved disputed wording. Give the drafting tool the approved decision request, the supporting observations and the open conditions. Do not ask it to invent a compelling business case from gaps in the notes.
Create a six-slide meeting-summary presentation from the supplied notes. Lead with the decision requested. Separate decisions, observations, open questions and actions. Preserve every unit, denominator, condition and uncertainty. Do not infer an owner, date, budget or result that the notes do not contain. Put detailed discussion history in an appendix. End with the next action and the question that must be reviewed.
Read the proposed first and last slides together. The first should ask for the decision that is actually open; the last should say what happens next without inventing an approval, deadline or owner. Keep the complete notes available as the supporting record.
