Emergency Alert Testing Best Practices

There's a bit of thought process and discussion that goes into defining an emergency alert plan for your particular environment.

Who in your organization needs to be involved in defining your emergency alert plan?

Typically, defining an emergency plan for an organization involves stakeholders beyond those who manage your Revolution system. It's easier to identify all those who should be involved in the planning from the beginning.

• Does your organization already have an emergency protocol in place?

  Chances are some sort of emergency protocol is already documented. There may be local, state, or federal emergency protocols in place. (For example, schools may be required to have certain emergency protocols in place.)

  Obtain a copy of any existing protocols and find out who put them in place. You'll likely want to include these people in your emergency alert notification system discussions. This way all the stakeholders stay on the same page. It also removes an avenue of confusion in an actual emergency.

• What scenarios constitute an emergency?

  This discussion identifies for you how many emergency alerts you need to create – for example, fire alert, chemical spill alert, lockdown alert, panic button alert, etc.

• What message or audio needs to be conveyed for each emergency alert?

  Does the alert need to play continuously or just for a set number of times?

• For each emergency alert, define who needs to receive it and how.

  First, for each emergency alert, define who needs to receive it. Are there people with special needs (disabled, children, elderly)? Does a security guard or police officer need to be notified as part of the alert?

  Next, identify the kind of environment people are likely to be in when they receive the alert? For example, are you notifying warehouse workers who might be working in a loud environment? Maybe you're notifying people who may not be at their desk; can they receive the alert on their cellphone? Or you might be notifying a school and teachers have to be able to hear instructions while escorting children off the premises.

  This discussion identifies for you whether the emergency alert needs to go to speakers, phones, mobile devices, people's email and text messages, etc. This, in turn, helps you identify what you need to configure in Revolution. Do you need the emergency alert set at a high volume? Do you need to ask people to download the Mitel Revolution Mobile Application app so they can receive alerts that way? People receiving notifications to their personal contact methods (smart phone, email, text, etc.) will need to be set up as contacts in Revolution.

• Who will trigger emergency alerts?

  Identify your emergency response teams, their specific roles and tasks. During an emergency there may be a lot of noise or chaos. Those in charge don't want to have to think about what they should do.

  How will they send the emergency alerts – from a desk phone, from their desktop, from their mobile device, by pressing a panic button or activating some other device?

  Are the people in charge of sending emergency alerts the same ones who will create the notifications in Revolution? If not, make sure those who are sending the alerts are familiar with the notifications you've set up and how to trigger them. And make sure those sending notifications have the proper user roles assigned in Revolution.

  These discussions help you identify who needs to have access to Revolution and what user roles they need. It helps you define what triggers you need to create and assign to your emergency alert notifications – line numbers so an alert can be initiated from a phone, Mobile app triggers and assistance buttons, pushing a panic button, etc.

• Will you include response options with your emergency alerts?

  Revolution provides the ability to include response options with notifications so in an emergency, people can quickly check in to identify if they're safe or need assistance. When response options are included, identify who in your organization is in charge of monitoring the responses and what actions they should take in reporting the responses and sending assistance if required.

As you're defining your emergency plan, make sure to document it.

• Where should the document live so that it is easily accessible to those in charge of various tasks and implementing the plan?
• Who is in charge of maintaining and updating the plan?

While it's important to document your plan, a common pitfall is writing a lengthy, overly detailed plan that those responsible for executing it don't read. Your plan should be clear and concise, but not overwhelming.

• Follow your documented plan to test it.

  In all likelihood, you'll need to initially test your plan more than once and make adjustments as you go. After a test run, ask your team:

  • Did the key players tasked with sending emergency alerts know what to do? Do roles and tasks need to be more clearly defined?

  • Were key players able to send the emergency alert notifications easily? Does anything additional need to be documented?

  • Did everyone who was supposed to get the alert receive it? Are speakers loud enough? Are text and images displaying correctly on phones? Can the audio be heard over any alarms that might be going off? Is the message itself clear?

• How often should you test the various emergency alert scenarios?

  Frequency of testing may depend on the type of organization you are. For example, a business might conduct a fire drill once a year, but a school might be required by state law to conduct a minimum of two emergency drills annually (fire, lockdown, evacuation, etc.). Know what your state and local requirements are.

  Note: It is suggested that you test your scenarios at least once a quarter.

  This test process should follow the documented test plan, send all emergency alert notifications, and verify that all devices and recipients received the emergency alerts. Update your test plan and documentation as needed.