Turning meeting notes into a presentation is not a matter of copying every sentence onto a slide. The useful deck is a decision path: what was discussed, what was agreed, what is still uncertain and what needs to happen next.
Start with the notes as evidence, then use Presenti’s text-to-presentation workflow to propose an editable outline. Keep the source notes beside the draft so that every important claim can be checked before anyone presents it.
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.
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: approve a two-week pilot only after the data source passes security review. Do not ask for an unrestricted rollout.
- Reason for discussion: incomplete support requests are creating follow-up work. Show the 20-of-80 count; do not turn it into a user adoption rate.
- 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 prepares the prototype for the next discussion on Monday. Monday is a review point, not an invented 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.
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.
5. Give the slide draft a controlled input
Paste a cleaned brief rather than an unfiltered transcript. Tell the drafting tool which facts are illustrative, which figures are observed and which statements are still uncertain. Ask for an editable outline and flag missing evidence instead of asking the tool to make the story sound complete.
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.
Review the proposed outline before spending time on visual polish. Check that the first slide answers what the group must decide, that every number has a source, and that no open question has quietly become a promise.
