Why Should I Test My ENS?
You should test your Emergency Notification System regularly, just as you would test your fire alarms. We recommend testing all your contacts and devices on a quarterly basis. Testing your ENS regularly is important because:
- Bad data is the number one reason for failed messages. Testing your ENS helps you find bad data.
- It can identify failure points in communication routes that may prevent emergency messages sent via email, phone, SMS, and push from reaching recipients. This is particularly important if you have a large organization that is geographically dispersed.
- Corporate email bounce policies change frequently. Testing often will ensure you’re not blacklisted.
- Since ENS is used infrequently, regular testing gives your team an opportunity to practice and prevent human error during an emergency.
- It helps recipients become familiar with the sender and format of messages so that emergency messages aren’t ignored.
How Do I Test My ENS?
We recommend the following best practices for an ENS test:
- Alert recipients in advance of an ENS test using your organization’s preferred communication method, such as corporate email, newsletters, or intranet. Provide continual updates on upcoming tests and the importance of these tests and recipients’ participation.
- Test both one-way and two-way messaging and note any differences between the two. They may use different routing, so this will allow you to test both.
- Test the system the exact same way that you would use it in a real scenario. If you activate a plan, your test procedures should activate a plan. If you use an ad-hoc message, your test procedures should use an ad-hoc message.
- If you use plan activation, we strongly encourage you to use procedures that clearly separate your test and live plans to avoid activating a live plan by accident. Sending a live message during a test may degrade confidence in your program.
- Store your test plans in a different location from your production/live plans.
- Create test user accounts that do not have access to production/live plans and create live user accounts that do not have access to test plans.
- Document and stress the importance of selecting a test plan during tests within your user guide or documentation process.
- Add a confirmation step in your plan that clearly indicates LIVE or TEST acceptance prior to the alert going out. Building a workflow for approval is a great way to avoid incorrect activations.
- Your test message should clearly state that it is a test:
- Add TEST, TEST, TEST to the subject line and the beginning of each message.
- Add “This is only a test” at the beginning and end of each message and repeat it for voice communications.
- For SMS, it’s acceptable to simply add the word TEST or TST to your message, but you should communicate this with users ahead of time.
- Include details about what the message would have included if this were a live/real event.
- Ask recipients to respond on each device on which they receive a message. For example, if the test sends messages via email, phone, and SMS, recipients must reply to each message individually. Let recipients know this requirement in advance when you advise them of an upcoming test. This will confirm that recipients received the messages and can respond on each of their devices, which will add significant intelligence to your data quality indicators for review.
- Review and report on the results of your test formally to management. For any devices that failed or that did not respond, send one follow-up message. Develop a list of corrective actions, assignments, and target dates for follow-up. This will help you work with your colleagues to improve data quality and recipient engagement.
Regularly scheduled tests, performed correctly, can not only test the underlying technology, but the many factors that can cause issues in communications success. This will provide confidence in your ability to communicate during an emergency.
