Rehearse the Presentation Setup, Not Just the Talk
Rehearse the Presentation Setup, Not Just the Talk
Three clean run-throughs of the deck. The story lands, the timing holds, the jokes survive. Then the meeting starts and the first forty seconds go to discovering that nobody can hear the customer clip, that a window with an internal note flashed across the shared screen, and that the link in the invite asks for a login your customer doesn't have.
None of those are content problems. They're delivery problems, and they live in the gap between the file on your laptop and the screen, speakers and browser of the person receiving it. You can find them on Friday, quietly, with one other person. Or you can find them on Tuesday with an audience watching you troubleshoot.
A setup rehearsal is short. It ends with a list of specific fixes, each one owned by a person, plus a clear statement of what is still unresolved and what the fallback actually covers. And it records which version of the file was checked, because that is the only thing you can honestly claim was tested.
The worked example below is invented — a plausible rehearsal record, written to show the shape of the work. Nobody ran it. No software was configured, no settings are being reported for any real product, and none of it is evidence about how your tools behave.
Reproduce the delivery route that can fail
Four things make up the route, and each can break on its own:
- the file or export the audience will actually see, at the version you will actually present;
- the device and screen you present from, and how its picture reaches people — room display, projector, or a share;
- how sound travels, if any slide carries any;
- the route participants use to get whatever they need on their own screen.
Rehearse in the intended configuration when you can. When you can't, write down the substitution and what it leaves untested. "We rehearsed from a home laptop on home wifi; the customer's network and their managed devices are untested" is worth more than calling the home laptop equivalent. It's also the sentence that stops you from claiming more than you checked.
Then put two people in place besides the presenter. The first is an observer who joins the way an attendee would — a different machine, signed in as a participant — and writes down what they actually receive. The second is someone on chat who can restart a session, change a share or fix a permission without the presenter having to leave the screen and start clicking. The presenter cannot be the observer, because the presenter's own screen is the thing under suspicion.
The invented rehearsal runs like this. Ashfield Labs, a fictional software company, has 45 minutes on Tuesday with six people from Bracken Vale, a fictional customer, to walk through a claims-routing product. Dana presents from her work laptop and shares her screen. Ivo joins from home on a second laptop using the attendee link and writes down what he receives. Rosa is on chat and can restart the session or fix a permission. The file is bracken-walkthrough-v4.pptx: 41 slides, a bar chart on slide 9 with a footnote qualification, a 38-second customer clip on slide 12, and a live rule-building workflow that starts after slide 14. The declared fallback is demo-fallback-rule-builder.mp4, two minutes ten seconds, opening on a frame that reads "Recorded — not live." Participants are supposed to get a PDF of the deck and a description document from a link in the invite.
The rehearsal is Friday afternoon, 25 minutes, four days early. Nothing here reproduces Bracken Vale's laptops or their network, and the record says so.
Look from the audience's side
Give the observer tasks that require text, not impressions. Not "did that look okay" but "what did the footnote on the chart say," "write down the sentence you heard in the clip," "did the screen ever show anything that wasn't a slide." A familiar slide appearing somewhere on the presenter's display proves nothing about what arrived.
Four things came back.
The chart's qualification didn't survive the trip. Ivo could read the bars and the headline on slide 9, but the footnote — "Commercial claims only; Medicare Advantage excluded" — was set small enough that at the size he received it, he couldn't read it. The line that keeps the chart honest was invisible. The fix was to shorten it, enlarge it, and say it aloud as well, so the qualification arrives twice. Retest: Ivo read it back correctly.
The clip played for Dana and nobody else. Ivo heard nothing for 38 seconds and watched a still frame. Dana heard it perfectly through her own speakers, which is exactly the trap: the presenter's local playback is not evidence that sound left the building. The fix in this configuration was to share audio from that source rather than only the picture. If your tool can't pass that audio, declare the substitute in advance — Dana says, out loud, "the clip won't play for you, here's the line that matters," and reads the sentence, with the transcript sitting in the description document. Retest: Ivo wrote down "we stopped reconciling by hand in February."
A note went out on the share. Four minutes into the rehearsal, Dana switched windows to check a cue and Ivo's feed showed her notes window for about three seconds. The note was a dummy — "DO NOT RAISE THE MARCH RENEWAL" — deliberately not her real notes, so that finding it cost nothing. That's the reason to rehearse with dummy material: you're testing whether private material leaks, and you'd rather learn it from a fake. The fix was to share the application window instead of the entire desktop, and to close the customer inbox, the chat and the calendar first. Retest: Ivo confirmed the only thing he ever saw was slides.
The observer's account is the whole record here. Dana would have reported "clean run" on all four points.
Check direct access and recovery
Screen sharing is not the material route. Participants often need the deck, a transcript, a description of a chart, or captions — things they read at their own pace, on their own device, possibly before or after the session.
Ivo clicked the link in the invite and got a sign-in page for Ashfield's own tenant. He could open neither the PDF nor the description document. Left unfixed, six attendees would have arrived with no deck, no transcript of the clip, and no accessible version of that chart footnote. The repair was to attach both documents directly to the invite and drop the folder link unless it opens without an account. Retest: Ivo opened the attachments signed out in a private window on his home laptop. That approximates a recipient's condition; it does not reproduce one. Rosa confirmed with the customer's coordinator on Monday morning that both attachments opened on a managed machine, and the folder link came out of the invite.
This is the narrow place where published accessibility guidance is useful. The W3C Web Accessibility Initiative's guidance on making events accessible treats event setup — sound, visibility, connectivity — as part of the plan, and asks presenters to describe relevant visual information; its materials and multimedia sections point toward giving participants a route to content they can use directly, not only a picture on a shared screen. That page is general guidance for events, not a set of application settings, and it isn't a conformance or legal finding about your meeting. The format-specific part still has to be worked out in your own tool, against its current documentation, with a sample you're permitted to use.
The demo transition was the worst of it. At the end of slide 14, Dana ended the share, brought the browser forward and started a new share of that window. Ivo's feed showed "Dana stopped sharing" for 22 seconds of nothing. The audience gets a black rectangle and a presenter who has gone quiet, right at the moment the product is supposed to appear.
The fix was to stop ending the share. Dana pre-opened the product in a browser window, already signed in, and changed what she was sharing from the slides window to the browser window instead of stopping and restarting. Whether your tool allows that without a break, and what it calls it, varies — check the current documentation rather than assuming. If it can't be done, plan for the gap: say one sentence about the switch, keep talking, and know where the fallback lives. Retest: the transition took six seconds and Ivo's feed never returned to the stopped-sharing state.
Then rehearse the fallback itself, before you need it. Dana played demo-fallback-rule-builder.mp4 from the same share, and Ivo confirmed the opening frame — "Recorded — not live" — was legible at the size he received. If it runs, Dana says so before pressing play, in words. And the record should carry what the substitute cannot establish: the recording shows the rule being built, but it cannot show the customer's own data, cannot answer a question about their own claims, and does not demonstrate that the product is working today. It answers "what does this flow look like," not "does it work for us."
Turn findings into a short retest list
One line per finding: the step that failed, what the audience would have experienced, who owns the repair, and either the fix or the declared limitation. That's the whole artifact. It fits on a page, and it's readable by whoever ends up presenting.
Then retest the changed route, not the talk. Dana didn't re-run 45 minutes after enabling share audio; she replayed the clip and asked for one phrase. The four retests took about 25 minutes total, because each one tested only what had changed. Running the whole presentation again by habit feels thorough and quietly hides which fix actually worked.
Watch out for the version problem, which is where most of these records go wrong. The checked file was bracken-walkthrough-v4.pptx, 41 slides, last saved Friday at 14:45, with the retests at 15:00, 15:05, 15:12 and 15:30 all run against that save. Note the time, not just the name — the same filename gets re-exported over itself, and "we tested v4" can quietly mean a different v4. If someone edits a slide on Monday morning, that slide is unchecked; the slides nobody touched keep their result. Don't re-run everything and don't pretend the check still covers the deck.
The invented record closes with this:
Repaired and retested — chart footnote (Dana, read-back passed); shared audio (Dana, transcript phrase heard); note exposure (Dana and Ivo, slides only); demo transition (Dana, six seconds, no share drop); participant materials (Rosa, attachments opened on a managed device Monday 09:20, folder link removed from the invite).
Unresolved, and on the cue card — the fallback recording covers the rule-building path only, not the reporting screen, which was never recorded; and no part of this reproduced the customer's network or their devices. The closest available test was a home connection, which is not the same thing, and the record says so rather than rounding up.
Two of those items are the kind of thing a team would rather not write down. They're also the difference between a rehearsal that ends with "the deck opened fine" and one that ends with a list of things you already fixed and a shorter list of things you've decided to live with.
Frequently asked questions
What is a setup rehearsal supposed to cover?
It should reproduce the delivery route that can fail: the file or export at the version you will present, the device and screen and how its picture reaches people, how sound travels, and the route participants use to get materials on their own screen. Rehearse in the intended configuration when possible. When you cannot, write down the substitution and what it leaves untested.
Who else should be involved besides the presenter?
Use an observer who joins the way an attendee would, on a different machine and signed in as a participant, and who writes down what they actually receive. Use a second person on chat who can restart a session, change a share, or fix a permission without the presenter leaving the screen. The presenter cannot be the observer, because the presenter's own screen is the thing under suspicion.
What did the invented Ashfield Labs rehearsal find?
It found that the chart footnote was unreadable at the size received, the customer clip played only for the presenter, a notes window briefly went out on the share, the invite link required a tenant sign-in, and the demo transition caused 22 seconds of stopped sharing. Fixes and retests included enlarging and saying the footnote, sharing audio or reading the transcript, sharing the application window after closing private windows, attaching documents directly, changing the share without stopping, and rehearsing the fallback recording.
Why record the time as well as the filename?
The same filename can be re-exported over itself, so 'we tested v4' can quietly mean a different v4. Record the checked file and its last save time, and run retests against that save. If someone edits a slide later, that slide is unchecked; slides nobody touched keep their result. Do not re-run everything or pretend the check still covers the whole deck.
What did the rehearsal leave unresolved?
The fallback recording covers the rule-building path only, not the reporting screen, which was never recorded. No part of the rehearsal reproduced the customer's network or devices; the closest available test was a home connection, which is not the same thing. The W3C WAI guidance on accessible events is general guidance, not application settings or a conformance or legal finding, so format-specific behavior still has to be checked in the actual tool and current documentation.