Do those of you who rely on automated notification systems test the process regularly? I know quite a few organizations that have invested in these software products and/or internet based services but yet never test them. I think that presents a huge risk if and when you need to implement the service. There are a number of issues with these products that you should make sure you have vetted besides validating that the phone numbers entered are correct.
One thing you should find out is what displays on a phone’s caller identification when the service is activated. Some products allow you to customize the display while others may display an 800 number or the name of the service provider. Many of your employees may see the caller ID displayed, not recognize it and ignore the phone call. This can result in a very low percentage answer rate at time of crisis.
Also, if your service provides a computer generated voice message from typed text, you will want to make sure you are comfortable with how numbers and company jargon is interpreted by the voice module. I have used several systems where you needed to be creative with the use of spaces, periods or commas to ensure the proper flow of the message. Phone numbers entered as we normally type them were read too fast or specific company jargon was mispronounced and needed to be phonetically typed for the voice module. People typing in the messages have to be trained to enter the message so it is read properly by the computer voice system. One example where this became an issue was with an airline company where the employees regularly typed in airport codes in messages. The message, “Problem on Flt 999 from EWR to LAX”, did not come across well when sent out as a voice message.
You may also need to make sure people are trained in the response method to indicate they got the message and, in some cases, to indicate their response posture. And, be sure that there is no confusion with how to respond if the message is being picked up as a voice mail message. I worked with one company where the message gave instructions to “Press 1 to listen to the rest of the message” or “Press X to indicate if you can respond”, etc. This worked great if you received the message live, but pressing numbers while listening to the message in voice mail had no effect. Employees were confused as heck while trying to follow these instructions in voice mail. The messages had to be altered to indicate, up front, that if you are listening to the message in voice mail you will not be able to respond directly.
You may also need to test the system to see if there are any problems caused by the call volume. I have seen, on more than one occassion, where business phone numbers were the primary number called and by issuing an alert, the company PBX was so innundated with incoming calls that it brought the system down. This, needless to say, was a big problem.
One thing people should know and your management teams should be made aware of is that even for systems that are perfectly implemented and regularly tested, an 80% hit rate on weekends and after hours is still a very good response. You should test your systems and track the success rate to get a realistic sense of what kind of response you can expect during a real emergency.
I understand there may be a cost incurred by phone call and doing too many tests can become expensive. I also am cognizant of the delicate balance between making sure people know how to send a message and how to respond to the message with creating a “cry wolf” syndrome where too many tests result in people not being responsive to the phone calls. It is up to us to make sure we come up with the proper schedule and frequency of these tests to ensure the use of this tool is effective and efficient at time of need.