Adam Arrowood of Georgia Institute of Technology was tempted to end his HighEdWeb 17 presentation after one slide. Even though his topic, “Planning for Emergency Campus Communications” is a serious one, his message can be distilled simply:
- Have a plan
- Test that plan
- Don’t let your server melt
Of course, Arrowood provided his audience with much more detail than that during his talk in Hartford Tuesday afternoon. Georgia Tech has developed a robust emergency communications plan, informed from experience. The campus has experienced tragedies recently that have impacted their processes as well.
Tech has divided emergencies into slow and fast emergencies, Arrowood said. Slow emergencies can be weather closings, epidemics, traffic accidents for example. Fast emergencies happen quickly and communications unfold quickly– they can be bomb threats, active shooters and more.
The plans for each differ, but there are tenets that must be consistent, Arrowood said.
First, develop a plan. The end result should be a written plan and checklist for communications scenarios, outlining actions before during and after the crisis, he said. “Get the right people involved before an emergency happens,” Arrowood said. That means IT, communications and emergency personnel, all working together. Develop messaging templates that allow for quick communications and establish who is sending communications on what channels and when. Even consider which campus office will define that an emergency is in fact underway (usually that’s going to be police, Arrowood said).
Your plan should know the limitations of your communications channels and establish which channel will be the primary mode of communication. Tech decided to send traffic to its emergency web site, so that messaging across channels would remain in sync, Arrowood said. And determine who will say what after the crisis has passed.
Your web messaging should be uncluttered, with simple plan text, quick loading website and a mobile first design.
“I call it web design for panicked users,” Arrowood said.
Secondly, test that plan frequently, so that it can be refined. Test on as many channels as possible from SMS to web to social. And keep the language innocuous so that it is easily identifiable as a test. Georgia Tech made that mistake, Arrowood said, and their audience ignored the TESTING language and focused on the crisis language, worrying that an actual emergency was underway.
It is also important to seek feedback from users after the test, he said. The answers from those users will usually challenge your assumptions.
It’s also critically important to figure out how you will handle the increased load an emergency will deliver to your web servers. Not only will you have more users using your site, they will be refreshing constantly, increasing the stress on your web server architecture, Arrowood noted. A school needs to make sure its publication channel is unaffected by the load and make sure its system can run with no campus resources.
Georgia Tech decided to use an AWS S3 web bucket that could handle millions of additional hits and take traffic off campus. That came for a surprisingly reasonable cost, Arrowood said.
With those three precepts in place– having a plan, testing the plan and making sure their servers don’t melt– Georgia Tech feels better prepared to deal with the next emergency when it comes, Arrowood said.