Most meeting-recording advice assumes you're one of several people on a call, with a spare moment to glance over and confirm everything's running. Presenting removes that moment — your attention is on slides, on the argument you're making, on the next click, not on whether a red dot is still lit somewhere on the screen. The fix isn't to check more often. It's to set the recording up so it doesn't need checking at all.
Why presenting changes what "recording it" means
In a meeting you're only attending, the main risk to a recording is forgetting to start it. Presenting adds a second risk: assuming that because you're talking the whole time, only your microphone matters. It doesn't — system audio capture still needs to be recording everyone else's questions and comments, and anything a shared video clip or a slide with embedded sound is playing, none of which comes through a microphone pointed at you.
Step 1 — start the recording before you start presenting
Press record before sharing a screen or starting slides, the same as any other meeting. The few minutes before a presentation starts — people joining, a quick recap of the agenda, someone asking what's being covered today — are often the part most likely to get skipped if recording only starts once the slides go up.
Step 2 — share your screen normally; recording keeps running underneath it
Starting or stopping a screen share doesn't interact with the recording at all — they're two entirely separate things happening on the Mac at the same time. Whatever meeting platform is being used for the share, the same two tracks keep capturing regardless of what's currently on screen.
Step 3 — let the microphone track carry your voice, uninterrupted
The built-in or connected microphone keeps recording your side of the call the entire time you're presenting, the same as in any other meeting — there's nothing about talking continuously for twenty minutes rather than in short bursts that changes how the microphone track works.
Step 4 — let system audio carry everything else, including your slides' own sound
Questions from attendees, a colleague chiming in, and any audio a slide or video embedded in the presentation plays are all part of what the Mac is outputting during the call, so they land on the system audio track the same way a remote participant's voice would. Nothing needs to be configured specifically for a presentation's own audio to be included.
Step 5 — stop recording after the call actually ends, not after your slides do
Reaching the last slide isn't the end of the meeting — a Q&A section, a closing discussion, or people staying on to ask something off-script often happens after the formal part is done. Stopping the recording when the presentation itself ends risks losing exactly the part of the meeting most likely to contain a question worth having the answer to later.
What changes about relying on a transcript when you were the one talking
A transcript built from a meeting you presented in reads differently from one where you were mostly listening — it's mostly your own words, in your own structure, which can make it feel less necessary to review. It's worth reviewing anyway: the generated minutes capture what attendees asked and said in response, which is often the part a presenter, focused on their own material in the moment, absorbed less of than they think they did.
A remote presentation, given entirely from a Mac
The setup described above assumes the whole call — your voice, your slides, everyone else's questions — is happening through the one Mac doing the presenting. That's the common case for a remote presentation and it's the one where both tracks matter most: your microphone catches you, system audio catches the call's platform and everything it plays, and neither depends on anything beyond the Mac itself being involved.
A presentation given in a room, with the call also being recorded remotely
If the presentation is happening in a physical room with a mix of people present and people dialling in, the Mac only ever captures what it can actually hear — your voice through its microphone, and whatever the call platform running on it is outputting. It has no way to separately capture audio from a room's own PA system or a projector's speakers if that audio isn't also routed through the Mac itself; what gets recorded is bounded by what the machine running the recording is actually part of.
Why this matters more for a founder giving an investor update
A founder giving a recurring investor update is often the one person talking for most of a call, which makes the temptation to treat the microphone as the only thing that matters strongest exactly where it's most wrong — the investor's questions and reactions are often the part worth reviewing afterward, more than a repeat of material that was already written down in the deck being presented.
Comparing this to recording with a phone propped up in the room
Before something like this, the alternative for a presenter wanting a record of their own talk was often a phone recording itself from across the room — which is exactly what a phone's microphone alone can capture: the presenter's voice, muffled by distance, and little to nothing of the audience or the call's own audio, since a microphone across a room hears everything at once rather than the call's own audio and a voice separately. Two tracks captured at the source, from the machine actually running the call, is a different setup entirely, not a better-positioned version of the same one.
Recovering from a recording that only captured the microphone
If it turns out afterward that only the microphone track came through — a sign that the system audio permission was never granted, or got reset by a macOS update — there's no way to retroactively recover the other side of that specific call. The fix going forward is checking the permission once, ideally before the next presentation rather than after noticing a gap in one that already happened.
Presenting from a second monitor, with the meeting app on the first
A common setup for presenting is slides full-screen on one display and the meeting platform's own window — showing who's talking, the chat, the participant list — on a second. Nothing about that arrangement changes how the recording works: system audio capture reads what the Mac is outputting regardless of which screen a given app's window happens to be on, and the microphone is unaffected by how many displays are connected.
Presenting without sharing a screen at all
Not every presentation is a slide deck — sometimes it's a spoken update with nothing shared on screen. The same two tracks apply here without any change: the microphone still captures the presenter's voice, and system audio still captures everyone else's questions and comments, whether or not anything is being visually shared. Screen sharing and recording are unrelated to each other on a Mac, so the presence or absence of a share changes nothing about what gets captured.
A presentation given partly from notes, partly off the cuff
Most real presentations aren't read verbatim from a script — there's a planned structure and then genuine back-and-forth once questions start. Both halves get captured the same way: the microphone doesn't distinguish between a rehearsed sentence and an improvised answer, and neither does system audio when it comes to a question interrupting from the call. The recording doesn't need to know which parts were planned to capture all of them equally.
What to check once the presentation is actually over
Because there's rarely a natural moment to glance at the recording mid- presentation, the first real check tends to happen afterward — confirming the recording actually ran the whole time, rather than stopping partway through because of something like the Mac going to sleep. A recording that stops when the Mac sleeps is a separate, known failure mode worth ruling out specifically after a long presentation, since a presenter often has the Mac's lid propped open and attention elsewhere rather than checking the screen stayed awake throughout.
Why a presenter benefits from the transcript more than they expect
It's tempting to assume a transcript is mostly redundant when you were the one talking and already know what you said. In practice the more useful part for a presenter is usually everyone else's side — a question raised near the end that got a quick answer and no follow-up, or a comment from someone who was quiet through most of the call. Those are the moments most likely to be under-processed in the moment, precisely because attention was on the material being presented rather than on parsing every reaction.
Why it's worth doing a dry run once, not before every presentation
The one moment worth spending real attention on is the first time this setup gets used for a real presentation — confirming both tracks actually came through on a short test call, the way testing on a call that doesn't matter is worth doing before trusting a setup for something that does. After that first check, this becomes something that runs the same way every time without needing to be re-verified before each individual presentation.
A worked example, start to finish
A remote quarterly review runs forty-five minutes: fifteen minutes of slides, presented straight through, followed by half an hour of questions and discussion once the deck ends. Recording starts before anyone joins, so the opening small talk is captured along with everything after. Through the slides, the microphone track carries the presenter's voice uninterrupted; system audio carries a brief audio clip embedded in one slide, along with the meeting platform's own notification sounds as people join late. Once the deck ends and questions start, both tracks keep running exactly as before — nothing about switching from presenting to open discussion changes anything about how recording works. The minutes that come out afterward foreground the questions and answers from the second half, which is usually the part a presenter, focused on delivering their own material, retains the least of in the moment.
Presenting the same material to several different audiences
Some presentations repeat — the same deck given to a new client each week, or the same update given to a different stakeholder group each quarter. The recording and transcript are separate for each session even when the slides are identical, since what actually gets captured is the specific conversation around that particular delivery: which questions came up this time, what got clarified this time, who was in the room this time. Treating each delivery as its own recording, rather than assuming one transcript covers every version of the talk, is what makes it possible to tell later which audience asked which question.
Why none of this requires telling attendees anything different
Nothing about this setup changes what the meeting looks like from anyone else's side of the call — there's no bot joining the roster, no visible recording indicator broadcast to the room beyond whatever the meeting platform itself already shows, and no extra step for attendees to click through. Whatever a presenter would already say about a call being recorded is unchanged by the fact that the presenter, rather than an attendee, is the one who set it up.
What it costs, what it runs on
Recording both tracks through a presentation, and getting a transcript and minutes out the other side, is the default behaviour of Coii AudioNotes — $19 once, for three of your own Macs, with a 30-day trial that needs no card and no account. It runs on macOS 13 Ventura or later, Apple Silicon or Intel, the same as it does for a meeting where you're one voice among several rather than the one presenting.