I remember once seeing a tourism ad for Fiji that stated, "It's like Hawaii, before the war!" although it was clearly written by someone like my brother who lives in Fiji... not that I'm jealous or anything.
Well, what a week to be in Hawaii when a ballistic missile emergency notification gets accidentally sent to a wide audience, with the subtext of conflict between nation states.
That's one way to interrupt your Hawaiian Discount outlet shopping experience, or Mai Tais by the pool in Maui, or catching a nice barrel at Pipeline.
Even I got an emergency notification from one of my colleagues on Saturday morning informing me about the emergency missile notification even though I'm on the West Coast of the US.
Most emergency management agencies that we deal with here at Noggin have a set of standard procedures for different types of incident response.
Sure, some agencies are less mature than others in the sense that they still have to work out how some of these standard emergency procedures apply to them and their function, and some just haven't been down the path of developing or agreeing to the operational procedures. Throw a new set of people, or a new function, or a new piece of software into the mix, and you'll find that you have to rewrite your procedures anyway.
And then other agencies, who are quite mature, have a set of procedures for everything and anything (sometimes to the detriment of actually responding effectively to an incident), and have committees and processes for regular and continuous business improvement. Not that they overthink their processes...
And often, part of these procedures is developing standard communication templates for standard notifications in relation to different types and severity of issues.
So, enter "Ballistic Missile Crisis warning template 347".
From a crisis communication standpoint, it's easy to empathize with the poor person who accidentally pressed the emergency notification button in this instance.
Often a standard template will be set up in a crisis communications system, ready for expedited use, when time matters most. Someone needs to enter that template information, generate the distribution list, and then test it. Click the wrong button, and bam! ... potential mass panic.
But there are simple tools and checks to ensure that this doesn't happen, including the following:
1. Whitelist Draft Communications
Ensure that draft communication is whitelisted, meaning that it can't be sent out to the crisis communications gateway. That way, if someone does hit "Send" on a sensitive message to a large distribution list, it doesn't go anywhere. We frequently do this at Noggin, particularly for user acceptance testing systems, and when the distribution list can be wide.
2. Basic Security
Setting up your basic security model so that only certain staff can create messages, while other more trained, or more senior staff can send messages is a good way of dealing with the simple issue of - 'someone pressed the wrong button because they didn't have enough training'.
If you have a workflow building tool, you can enforce some of the above security in a similar way so that one person can set up a message template and set up the initial request to send the message, before it gets published.
4. Validation and Naming Conventions
And another, simpler UX element to help enforce the severity of the action is simple validation - "Are you sure you want to delete that critical document?" or "Are you really sure you want to overwrite that Excel spreadsheet?" or "Are you really, really sure you want to send a Ballistic Missile notification?" You can give the user several prompts that a message is actually getting sent out so that they have time for course correction should they need to. Because let's be honest, we're probably all guilty of saving over a document some time when we were half brain dead, undoing hours of hard work.
Naming conventions are also important - when you're naming templates, ensure that there are clear descriptions so that it's apparent what the message refers to, what level of severity, whether it's a test of final broadcast, and a basic time period of relevance.
5. Two-factor Authentication
If you have two-factor authentication built into the functionality of a crisis communications systems, this is a good way to ensure that the message has another gate of approval before it gets distributed. So, the person authorizing the final message for distribution could be sent a code to their mobile via SMS in order to release the final message. Not quite the nuclear codes - but that's a whole other topic.
Bear in mind, we don't quite use two-factor authentication in this way in Noggin, although we do have it for logging in, but that's something for the product roadmap.
If you're an existing Noggin OCA user and would like to read more about some of the safeguard features we've built in to the Noggin OCA platform, check out some of the Knowledge Base* articles linked below:
- Set up communication templates and use them in workflows
- Common Alerting Protocol
- Push notifications
- And more!
If you're new to Noggin and are interested in learning more about how we can help your organization manage disruption smarter, request a demonstration of our platform to see these features (and much more) in action!
You can also email us at firstname.lastname@example.org ... although, we will take any accidental emergency notifications sent to this address with a fair bit of skepticism.
*Please note, you will need a Noggin Support Portal account in order to access the portal. If you have questions about your Support Portal credentials, please reach out to your Noggin Customer Success Manager or Noggin Account Manager for assistance.