A speaker’s personal laptop is an unverified endpoint. It has not been through your load-in, it does not answer to your imaging standard, and it will arrive at the session with whatever OS updates, browser extensions, VPN clients, and power settings the speaker happens to be running. The demo itself may be excellent. The delivery vehicle is unknown.
This is not a reason to ban personal laptops. Speakers often need their own machine because the demo depends on local credentials, a licensed tool, or a dataset that cannot leave their device. The practical response is intake: convert the laptop from an unknown into a known configuration before it touches the live session, and record a fallback demo that survives the laptop’s failure.
This article is written for the conference technical producer — the person who owns the go/no-go decision on the demo environment and who will execute the fallback if it is needed. The speaker owns the demo content and the fallback recording. The producer owns the checklist and the switch.
Why the producer owns the go/no-go
The speaker is the wrong person to decide whether the demo environment is ready, for a structural reason: the speaker will be on stage, talking, when the failure happens. The producer is the one who will cue the fallback, unmute the backup audio, or cut to the recording. The decision to run live or run the recording should sit with the person who has to execute the alternative.
That does not mean the producer overrules the speaker on content. It means the producer owns the environment question: can this laptop, on this network, through this platform, deliver the demo? The speaker owns the demo question: is this the right demo, and is the recording an accurate representation of it?
Pre-load-in intake: record the account type and join path
Most intake failures start with an assumption about how the speaker will join. Platform join rules are account-type and admin-policy dependent, so the intake must record the speaker’s actual account type and join path rather than assuming a generic link will work.
Google Meet is a useful worked example because its join documentation is explicit about the variables. A meeting can be joined from Google Meet, Google Calendar, or Gmail, and also by meeting link, phone dial-in, Google meeting rooms or third-party devices, or without a Google Account at all. Those are not equivalent paths, and they do not expose the same controls.
The account-type table matters because it changes who can get in. For a personal account, Google One, or Google Workspace Individual, all Google Account users can join the meetings you organize — with the documented caveat that some Workspace admins might stop their users from joining, and users who have not signed in to a Google Account must request to join. For Google Workspace for Education, the default is narrower: only users in your school and anyone who dials in with a phone, unless the admin changes it. For Google Workspace, the default is broader: all Google Account users and those who have not signed in, unless the admin restricts it to only users in your organization or anyone who dials in with a phone.
Two join paths deserve specific attention in intake:
- Not on the calendar invite. If the speaker is not on the calendar invite, they need to request to join and the meeting organizer or a participant must let them in. That is a manual step in the first minute of a session, and it should be rehearsed, not discovered.
- Joining without a Google Account. This is possible, but the organizer or a participant needs to let the speaker in. Same manual-step problem.
Third-party device joins are a separate category. If the speaker’s laptop joins through a third-party device, the documented behavior is that you must use the third-party controls, and without them you cannot use features like turning the camera or microphone on or off, meeting chat, recording meetings, admitting or removing other participants, or muting or unmuting other participants. If the demo depends on any of those controls, the producer should verify the demo can be driven with the controls that path actually exposes — before the session, not during it.
Record the speaker’s account type, the exact join path, and whether the speaker appears on the calendar invite. Those three fields are the difference between a link that works and a link that produces a request-to-join prompt while the room waits.
Network and device intake: capture, don’t invent thresholds
The intake form should record the laptop’s OS and version, browser and version, camera, microphone, and network path. These are fields to capture, not pass/fail thresholds invented for this article. The producer’s job at intake is to know what the configuration is, so that when something behaves differently in rehearsal than in the session, there is a baseline to compare against.
Two fields are easy to skip and expensive to skip:
- Network path. Is the laptop on venue Wi-Fi, a wired connection, a phone hotspot, or a VPN? A VPN that routes demo traffic through a corporate network can change latency and can block platform endpoints. Record it, and if the demo depends on a remote service, test the demo through that exact path.
- Power and sleep settings. A laptop that sleeps during a 40-minute session will drop the demo. Record the current setting and confirm it is changed for the session, then confirm the change is reversible after the event.
AVIXA describes its standards as recommended practices created by subject-matter experts, intended to support technology design and procedures that focus on reliability, competency and success. That framing is useful here: the intake checklist is a recommended practice for this event, not a universal standard. It should be written down, versioned, and adjusted after each event based on what actually broke.
Platform-join rehearsal: same link, same account, same device
Schedule a test join with the speaker using the same link, the same account, and the same device they will use on the day. A rehearsal on a different machine or a different account tests the wrong configuration.
The rehearsal should confirm, at minimum:
- The speaker can enter the session through the recorded join path without a manual admit step, or the admit step is assigned to a named person who will be present.
- Screen share works from the speaker’s laptop to the session, at the resolution the demo needs.
- Audio from the demo (if the demo has sound) reaches the session, and the speaker’s microphone does not create a feedback loop with the demo audio.
- Any platform controls the demo depends on — chat, recording, participant management — are available on the speaker’s join path.
- The demo itself runs from the laptop through the session, not just a static screen share.
Note that join behavior can differ by account type and admin policy, so a rehearsal that passes on one account type does not prove the session will pass on another. Record the account type used in rehearsal and confirm it matches the session.
Fallback recording: made before the event, stored off the laptop
The fallback recording should be a screen-and-audio capture of the demo, made before the event, stored where the production team can play it without the speaker’s laptop. The storage location matters as much as the recording: if the only copy is on the laptop that fails, the fallback fails with it.
Requirements for the fallback file:
- Screen and audio. If the demo has narration or sound, the recording includes it. A silent screen capture is not a fallback for a narrated demo.
- Full demo length. The recording covers the entire demo, not a highlight reel. If the speaker plans to run 12 minutes of demo, the recording is at least 12 minutes.
- Stored on production infrastructure. A shared drive, a production laptop, or a media server the producer controls. Not the speaker’s laptop, not a personal cloud account the producer cannot access.
- Tested playback. The producer plays the file end-to-end on the playback machine before doors open. A file that exists but will not play is not a fallback.
- Named file and location. The intake form records the exact filename and path, so the producer is not searching during the session.
If the demo contains attendee data, customer data, or anything subject to a privacy commitment, the recording inherits that commitment. The NIST Privacy Framework is a voluntary tool developed with stakeholders to help organizations identify and manage privacy risk; it is a reasonable reference for deciding what can be recorded, where it can be stored, and how long it can be kept. The producer should confirm with the speaker and the event’s privacy owner that the recording is permitted before it is made, not after.
Switch procedure: rehearse the fallback as a path, not an emergency
An unrehearsed fallback is a second failure mode. The switch procedure should define four things in advance:
- Who calls the switch. One named person. If the speaker calls it, the producer may not hear it. If the producer calls it, the speaker needs a clear signal. Pick one and write it down.
- What the speaker says. A short, pre-agreed line that buys the producer time to cue the recording without the speaker having to improvise. The line should be honest and brief.
- How the recording is cued. Which machine, which file, which output, and how the audio is routed. The producer should be able to cue the recording in under 30 seconds from the switch call.
- How the session returns to live. If the demo recovers, or if the session continues after the recording, the producer needs a defined path back to the speaker’s live audio and video.
The switch should be rehearsed at least once with the speaker, using the actual recording and the actual playback machine. A rehearsal that only walks through the steps verbally does not test the cue timing or the audio routing.
The copyable artifact: demo environment intake checklist
The following checklist is the artifact for the technical producer. It is designed to be copied into the event’s production document and filled in per speaker. Fields can be added or removed after each event; the checklist is a reversible fix, not a permanent policy.
DEMO ENVIRONMENT INTAKE CHECKLIST
Event: ______________________ Session: ______________________
Speaker: ____________________ Producer: _____________________
Date completed: _____________ Rehearsal date: _______________
1. ACCOUNT AND JOIN PATH
Speaker account type: ______________________________________
Join path (link / calendar / dial-in / third-party / no account):
___________________________________________________________
Speaker on calendar invite? [ ] Yes [ ] No
If no, who admits the speaker? _____________________________
Third-party device controls available? [ ] Yes [ ] No [ ] N/A
Controls the demo depends on: ______________________________
2. DEVICE
OS and version: ___________________________________________
Browser and version: ______________________________________
Camera: ___________________________________________________
Microphone: _______________________________________________
Sleep/power setting changed for session? [ ] Yes [ ] No
Change is reversible after event? [ ] Yes [ ] No
3. NETWORK
Network path (venue Wi-Fi / wired / hotspot / VPN): ________
Demo depends on remote service? [ ] Yes [ ] No
If yes, tested through this path? [ ] Yes [ ] No
4. REHEARSAL RESULT
Rehearsal date and time: ___________________________________
Same link, account, and device as session? [ ] Yes [ ] No
Join without manual admit? [ ] Yes [ ] No
Screen share works? [ ] Yes [ ] No
Demo audio reaches session? [ ] Yes [ ] No [ ] N/A
Demo runs end-to-end? [ ] Yes [ ] No
Notes: ____________________________________________________
5. FALLBACK RECORDING
Recording made? [ ] Yes [ ] No
Includes screen and audio? [ ] Yes [ ] No [ ] N/A
Full demo length? [ ] Yes [ ] No
Stored on production infrastructure? [ ] Yes [ ] No
Filename and path: ________________________________________
Playback tested on playback machine? [ ] Yes [ ] No
Privacy review completed? [ ] Yes [ ] No [ ] N/A
6. SWITCH PROCEDURE
Who calls the switch? _____________________________________
Speaker's pre-agreed line: _________________________________
Cue machine and output: ___________________________________
Cue time target (seconds): _________________________________
Path back to live: ________________________________________
Switch rehearsed with speaker? [ ] Yes [ ] No
7. GO / NO-GO
Producer decision: [ ] GO LIVE [ ] RUN RECORDING
Decision time: ____________________________________________
Notes: ____________________________________________________
8. POST-EVENT REVIEW (complete after session)
Did the demo run live? [ ] Yes [ ] No
If no, why: _______________________________________________
Checklist field that would have caught it: _________________
Field to add, change, or remove: ___________________________
Treat the checklist as a reversible fix
The checklist is a pre-event gate, not a permanent policy. After each event, the producer should review section 8 and adjust: add a field that would have caught a failure, remove a field that produced no signal, tighten a rehearsal requirement that was too loose, or relax one that added work without reducing risk.
The goal is not a perfect checklist. The goal is a known configuration, a tested fallback, and a rehearsed switch — so that when the laptop does something unexpected, the session continues and the audience never sees the recovery.
Questions that come up in intake
What if the speaker refuses to record a fallback? The producer’s options are to run the demo live with no fallback, or to decline the live demo and use a different format. That is a decision for the event owner, not the producer alone. The intake form should record the decision either way.
What if the speaker’s laptop cannot join the platform at all? The fallback recording is the session’s demo. The speaker can still present live from the session, with the recording carrying the demo portion. This is why the recording is made before the event, not during it.
How early should intake happen? Early enough that a failed rehearsal leaves time for a second attempt. The exact lead time depends on the event’s load-in schedule; the constraint is that the rehearsal must happen before the fallback recording is finalized, so the recording reflects the demo that will actually run.
Does this apply to hybrid events? Yes, and the room-to-chat handoff is a related failure point worth reading alongside this checklist: Why Hybrid Events Fall Apart at the Room-to-Chat Handoff. The intake checklist covers the speaker’s endpoint; the handoff article covers what happens when the session’s attention moves between the room and the chat.
What about platform-specific join documentation? Use the platform’s own documentation for the exact join rules, and record the account type and admin policy that apply to the speaker. The Google Meet join documentation is a useful model because it separates account types and join methods explicitly; the same discipline applies to any platform.