On the afternoon of Feb. 4, 2010, a man wielding a samurai sword attacked a post-doctoral fellow at the Georgia Institute of Technology. Within minutes of police arriving on the scene, twisted reports of the incident spread across Twitter, Facebook and other online channels. Fears that the attack might be the first of a coordinated attack on campus led students, faculty, staff, parents and the media to turn to the main Georgia Tech website for information and updates. Within minutes of police having control of the scene, the main Institute website was transformed to present a clear and precise message.
Luckily Georgia Tech had recently implemented and tested a ‘dark site’ plan for handling the official online response to various emergencies or crisis situations. Dark sites are pre-planned websites that are ‘dark’ or unpublished and are only made available in the event of a crisis.
I was a member of the Communications and Marketing team at Georgia Tech that worked on the development of the dark site strategy and system. I thought I would share a few of the key considerations that went into the development of our solution and also a few lessons we learned along the way.
Plan For Different Types of Response
Our crisis communication plan at Georgia Tech prepared us for handling different scenarios that may unfold on a university campus. Your dark site strategy should do the same. I was especially happy that our dark site system could handle notifying students and employees of campus closure due to inclement weather. No more waking up at 4 a.m. to alter the home page based on the decision of our Chief of Police. Your system should adequately handle different types and levels of responses.
Put the Communicator in the Driver’s Seat
Almost everyone is using some form of a content management system these days. If you aren’t, you probably should be. Your dark site strategy should put the control of setting the message and throwing the switch to enable the site directly in the hands of the decision maker, not your web developer. With a CMS-based website, that’s not difficult to do. When seconds matter you shouldn’t rely upon your IT department or web developer for responding to a crisis.
Domain/URL
It is important that your emergency response reside on the main entry point of your site for your targeted audience. For most sites, this is going to be your home page, but not always. Do your homework and find out. Using a secondary page that is in the waiting like yourdomain.com/updates or yourdomain.com/emergency requires you to redirect traffic to a unique URL using some automated method or through a link that requires a click of the mouse. Either way you are creating unnecessary traffic and load on your servers.
Traffic
A crisis situation will test the limits of your server infrastructure’s ability to handle very intense traffic. We’re talking requests per second here, not visits per day. You should strip your dark site or pages down to the absolute minimum total request size possible. This may mean a logo and a message. That’s all. No Javascript, large graphics or unnecessary database connections. You’ll be busy enough during the event of a crisis; don’t add a server crash into the mix.
Test It
A plan and a system are great to have but I have absolutely zero confidence in them until they’ve been tested. Fortunately for us, just months before the sword attack on campus, a local snowstorm presented us with the opportunity to test our system. But don’t wait for Mother Nature to provide an opportunity. Be proactive and develop a method and plan for testing your system.
I must admit that when I first heard of the samurai sword attack on campus, I didn’t believe it. In hindsight, I’m extremely glad we had a thought out plan and system that allowed our Communications and Marketing unit to control the message almost instantaneously. Can you say the same about your organization?
