5 simple steps to using a mass notification tool as part of your business continuity program
Mass notification is a broad term; depending on who you’re talking with, it can mean anything from a one way text blast, right up to a multi-channel two way communication system with all the bells and whistles … or anything in between.
With that being said, just because something qualifies as a mass communication tool, it doesn’t mean it’s suitable to use as part of your business continuity program. Emergency communication systems have the potential to really improve your organisational resilience, but they have to be fit for the purpose you are using them for. Putting it bluntly:
• SMS on its own is not resilient enough for a BC tool; single channel communications introduce a single point of failure.
• WhatsApp groups managed by individuals often circumvent your internal data protection policies; the chat messages might be encrypted, but personal data is being stored and managed on individual handsets with no controls in place.
• Tools that integrate 100% with your own infrastructure will in theory reduce the resource required to maintain them; in reality they are introducing a reliance on your own systems … and it might be your systems that are down.
Once you have a suitable tool in place, the next step is making it an integral part of your business continuity planning:
Regular testing is a must. Unless you’re really unlucky, you won’t be having a business disruption every day of the year. It’s entirely possible that you won’t have a live incident for weeks or months at a time, so keep everyone’s knowledge fresh by having a regular test schedule, and sticking to it.
This shouldn’t be a tick box exercise. A one way text message proves your service works but that’s all it does. Send test messages across all channels, and make it a two way message. That way, you are checking you have valid contact data for everyone, you are setting recipient expectations correctly for what to expect during a live incident, and you are testing their ability to understand the instructions you’re giving and respond to them appropriately. It’s much more effective to test these things now, than to find out you have a problem during a live incident.
Don’t forget about inbound routes. If you have a staff information line, make sure it’s updated whenever you send outbound messages. If you have an intranet that you can update, make sure you do this. Otherwise, you risk causing confusion.
Most communications plans focus on what happens during the actual disruption, but when you’re ready to return to “business as usual”, its equally important to communicate that message. Clearly and concisely letting everyone know that no further messages will be sent regarding this incident keeps everyone on the same page.
Whatever tool you’ve chosen, don’t be afraid to use it! Events that affect your IT infrastructure or hurt your productivity can be just as disruptive as disasters and major incidents. Similarly, you may not be affected by the actual incident itself, but the aftermath could cause you serious problems. If something has the potential to cause a disruption for you (large or small), you should be communicating about it.