Virtual event planning checklist

Eight weeks out — the decisions that are expensive to change

• Name the outcome, not the eventWhat has to be true afterwards for this to have been worth doing. If the answer is "people attended", the event is going to underperform and no amount of production will fix it.
• Fix the date, and check it against your speakers, not your calendarThe date you can host is not the date your speakers can rehearse.
• Decide virtual or hybridAn in-room audience is the single biggest change to scope, budget and risk. Decide it now, not later. It is also what moves the job into the higher price category.
• Confirm the platformPreferably one you already hold a licence for. A platform migration inside four weeks is risk taken for no benefit. See how to choose one.
• Lock the speakers in writingIncluding their agreement to attend a rehearsal. Getting that commitment at invitation time costs nothing; getting it three weeks later costs you the rehearsal.
• Set the budget bandKnow which of the two published categories you are in before you design the show.

Four weeks out — the build

• Draft the run of showMinute by minute. Who is on screen, what is playing, who hands to whom.
• Write the failover planWhat happens if a presenter drops, a screen share dies, a demo will not load, or the stream stops. Each needs a named answer and a named person.
• Open registration and start promotionRegistration that opens two weeks out is a registration number you have chosen to cap.
• Decide how Q&A worksLive, moderated, pre-submitted or triaged. This changes the run of show, so it is not a day-of decision.
• Plan the content before the eventWhich clips you want afterwards determines what you capture during. Decide it now, and see event-to-content.
• Assign the rolesHost, producer, technical director, Q&A moderator, and the person watching chat. One person cannot do two of these live.

One week out — rehearsal week

• Rehearse every speaker individually, on the real platformNot a group call about the event. The actual platform, the actual deck, the actual demo, from the location they will present from.
• Test the network each presenter will actually useThe hotel wifi, the home connection, the office VPN. Test the real one.
• Check screen-share permissionsEspecially on managed corporate laptops, where the permission dialog is the classic five-second fix that becomes a five-minute live silence.
• Run the demo end to end on the presenting machineA demo that works on the developer's laptop is not a tested demo.
• Send joining instructions, then send them againSeparately to speakers and to attendees, with different content.
• Dry-run the failoverActually drop someone and see whether the plan works. This is the step nobody does and everyone wishes they had.

On the day

• Open the speaker room 45 minutes earlyLate problems are cheap to fix; they are only expensive when they surface at start time.
• Check audio for every presenter individuallyAudio is the most common reason an audience leaves.
• Confirm the recording is runningThen confirm it again. A production that recorded nothing is the one unrecoverable failure on this list.
• Have a back-channel the audience cannot seeThe production team needs to talk during the show without it being on stage.
• Start on timeThe audience that showed up punctually is the audience you most want to keep.

Afterwards — where most of the value is left on the floor

• Send the recording within 24 hoursWhile it is still relevant to the people who registered and could not attend.
• Cut clips, do not ship the raw fileA two-hour recording has almost no audience. Six good two-minute clips have a real one.
• Answer the questions you did not get toIn writing, publicly. These are the highest-signal content prompts you will ever be handed for free.
• Debrief against the outcome you named eight weeks agoNot against attendance.
• Decide what recursA series amortises everything you just built, and it is why the second episode costs less than the first.

The lead-time reality

Common questions