The answer: Exactly one more test than you did.
Consider the following scenarios:
1) Near the end of your webinar, you plan to display a survey that you created in a third-party application such as SurveyMonkey. You have tested your survey, made sure you have the right link, and checked that it is operational from within the conferencing software. At the end of your webinar, you display the link and nothing comes up. SurveyMonkey’s servers crashed right at that moment.
2) You ran a webinar last week, displaying web content in a co-browser window inside the conference. This week you rerun the exact same webinar using the exact same conferencing software and the exact same content. It fails to display correctly. The vendor put in a version upgrade over the weekend and it introduced a bug that only shows up under your specific conditions.
3) You direct your attendees to a web link during the webinar. To make their lives easier, you use a redirect from a short, easy to remember domain name that you bought (like www.mydomain.info). You have tested the redirect and you know it brings up the correct destination site. But during your webinar, the web page fails to load for the attendees. Your domain host’s forwarding service has crashed and won’t redirect to destination sites.
4) You are bridging streaming audio between live presenters, a telephone conference, and a prerecorded audio clip during your webinar. You tested everything in a trial run to make sure the audio content fed into both the computer and telephone audio streams. When your webinar starts, the sound is unusable, fading in and out. With more lines open, the extra feedback and input sources overloaded the simple echo cancelation that worked during your testing. You needed to change the playback setup in order to prevent feedback.
Cute but improbable hypotheticals? I wish! Every one of these has happened to me personally. The internet is a scary place. Things go wrong in the most unlikely ways at the most unlikely times.
Your plan for reducing the possibility of a catastrophic failure has four parts:
A) Test everything during pre-production and setup. If you leave ANYTHING to an assumption that it will work as expected, that’s the piece that will give you a nasty surprise.
B) Retest critical links and content display immediately before your live webinar. Don’t rely on the fact that it worked last week when you tested it. Depending on the complexity of your webinar, you should be fully devoted to its administration anywhere from 30-60 minutes before show time.
C) Have as many backups in place as you can think of. If you are using a redirect with a short name, also have the long version handy with the full destination URL. If you are linking to ANYTHING on the web, have a plan for how to deal with a situation where it does not come up. Often this is as easy as making a simple Word document available for attendees with all links and resources. With the document in hand, they can visit your sites later when they are hopefully working again.
D) Script some emergency verbiage. Have sentences you can copy and paste into the attendee chat area to let them know you are working on the problem. Have some standard lines written down that you can say to your audience if something goes wrong. Your brain is going to be overloaded when it happens. You’ll be trying to diagnose, fix, figure out workarounds, and deal with confused or angry attendee chat messages. Your ability to improvise a calm and coherent statement will vanish.
Webinars are a great way to interact with many people, live and in the moment. That means that what used to be private frustrations with sporadic little internet glitches can easily escalate into image-crushing disasters that make you and your company look unprofessional. Plan, test, retest, and create backups. It’s the best you can do.
