how to choose an emergency notification system

Mission-Critical Emergency Notification

How to Choose an Emergency Notification System

http://www.missionmode.com


Page 1

Table of Contents

1. The Requirements

2. The Market

3. Ease of use

4. Administrators

5. Features Count

6. Features List

7. Integration with other Applications

8. Hosted or On-premise

9. Customer Service and Support

10. Vendor Trust

11. Resilience

Having requirements driven by business needs is crucial.

Let the Business Drive the ProcessLike any investment, doing some homework before going out to market will save you time and potentially costly mistakes when procuring an emergency notification system. This white paper is a guide that will help you ask the right questions, and determine your exact needs. It is designed to help you think through the process of defining, selecting and implementing a system.

Having a set of initial requirements driven by business needs is crucial. Without a clear understanding of business needs, you may make a purchasing decision that doesn’t really solve those needs. All too often, purchasing decisions are made with only a small amount of thought given to how the system needs to be used. This doesn’t have to be a drawn-out process and can easily be work-shopped to speed the process.

Before you begin to actually choose and review vendors, it is worth initially reviewing some applications to see whether there are features that you hadn’t thought about that could be worthwhile. Bear in mind, though, that these features should be tested against a real business requirement. It is easy to be dazzled by a wonderful array of features and lose sight of the core business drivers. There is a simple test to apply: will you use it and if you don’t, will it get in the way of the configuration or use of the notification tool?

Your requirements will then drive you towards a selection of appropriate vendors based on your initial review. Most medium-size and larger companies have procurement processes in place that determine the next steps. However, it is also useful to consider that there are many paths that the process could go down, based on how much the system will cost and how important the procurement is to your organization.

The RequirementsThere are a number of considerations that you need to keep in mind as you develop your list of requirements. The ones that follow are areas that are sometimes overlooked.

© Copyright 2013-2014, MissionMode Solutions


Page 2

Capable of adapting to your needs.

Where will you want to go after the first implementation?

Make sure you have a strategy to get good data.

Understand your unique needs as an organization

Determine whether the system will be needed for only emergencies or for other uses such as the incident management team, operational alerts, duty of care, supply chain issues, etc. You need to define the ultimate business needs that will be solved by a properly operated system. Will the system save money, avert risk, avoid regulatory action, or some other definable benefit? (Showing a positive ROI will increase the chances of your project being approved.)

The notification system you choose should be capable of adapting to your needs, rather than you having to change your own processes.

Understand the geography of your potential deployment

Where will this system be utilized? Decide if any international considerations need to be taken into account. Consider how you would envision deployment—country by country, region by region or all at once. If the system will be used internationally, it’s important to select a vendor that has a truly global infrastructure with points of presence across the globe.

Predict the future

Have an estimated plan for where you want to go after the first implementation. Consider whether use might be expanded into other business units. Will the ways in which you use the system change in the future? You don’t want to buy one system only to find out you have to swap vendors when you implement a phase two. How will the system fit into your overall crisis communications needs?

Determine where the contact data will come from

Will your contact data come from a central repository or will the data be entered by users (self-service)? Make sure you have a strategy to get good data. If the data will come from a central repository, will the notification system need to integrate with that repository? Or, will manual data imports be sufficient? If this data isn’t available currently, define how you are going to get the data. Vendors should be able to provide best practice on this, including how to clean the data once it has been initially gathered.


Page 3

Training needs should be minimal.

Will you be able to get IT resources?

Consider who will be launching alerts

What are their user priorities? Will they need to compose every detail of an alert from scratch or will you want to use customized templates to reduce human error? Determine whether these users need access to all possible notification templates or if they need to be restricted to certain templates. People are increasingly becoming mobile. Will you need users to launch and view alert results using mobile devices?

It’s also important to know how often users will be using the system to launch alerts. This may determine the need for user training. If a notification system is truly easy to use, though, training needs will be minimal. Also, people are increasingly becoming mobile. Will you need users to launch and view alert results using mobile devices?

Different industries are likely to be driven to different processes. Highly regulated industries (particularly safety- driven ones) are likely to establish standard operating procedures around the use of the notification system and therefore are likely to require more rigor in their configuration.

Consider who will be receiving alerts

Determine which types of devices they will be using. Will recipients need to respond to an alert with menu choices, not just an acknowledgement? Define the groups of users that will be receiving alerts. Organizations often need to have groups with membership based on user roles. Also, there is often a need to sequentially contact members of a group until someone responds in a certain way. Map out all the ways you will need to contact recipients.

Consider who will be administering the application

Their level of expertise will determine how important ease of use will be. You need to understand how much time they can dedicate to managing the system. Will you be able to get IT resources if the system requires them? Ideally, you want a system that is easy to manage and doesn’t require IT support. With some systems, a user with average skills will be capable of being an administrator.


Page 4

Implement where it will have the most impact.

A market focus similar to your needs.

Don’t restrict yourself to only the best-known companies.

Determine the next area within emergency response that will require software support

Establish what executive management thinks of the risk and investment requirements. Consider what they need to protect most: supply chain, customer support, agility, revenue, reputation, etc. You will generally want to implement a notification system into the part of the organization where it will have the most impact. This can be followed with implementations in other areas of the organization. For instance, if your supply chain is considered vulnerable, then using notification in that area might be of more importance than warning staff of an office closure.

The MarketThere are many notification vendors in the marketplace. Identify those that have a market focus that is similar to your needs. Determine if they are corporate or public-sector focused (this will influence whether the company is likely to have a system that will meet your needs). Do they sell directly or mainly through channels? If primarily through channels, find out if the company or channel partner will be responsible for support.

Is their product focused on emergency, operational, marketing or collections use? Make sure their product strategy aligns with yours. A different market focus tends to imply features that won’t be relevant, priorities in serving customers that won’t suit you, and a product direction that won’t converge with your requirements.

As the notification marketplace matures, many vendors are branching out into other application areas. How will this affect the investment in their core notification service? Can you envision using these capabilities in the future?

As you evaluate vendors, your understanding of the business needs will become crucial, deciding truly what is important and what is unnecessary and could detract from a timely and cost effective deployment. Think carefully about the non-functional requirements such as customer service, support and agility. Like any marketplace, the most visible companies don’t always provide these critical aspects as well as they could. Since this system will be used for emergencies, choosing for these non-functional requirements becomes even more critical.


Page 5

MissionMode’s emergency notification system is built for mission-critical enterprise use, yet it’s easy to use and manage.

Will IT support be needed?

Spend some time investigating the post-sales support options and how they will work with your processes. Check that the vendor will have continuity of people between pre- and post-sales so that your relationship and understanding built-up over the sales process won’t get lost.

Ease of UseThis is generally considered a subjective area of review, but there are important considerations that can introduce a degree of objectivity into the review. Users encounter the application at several levels: configuration and administration; alert invocation; receiving and responding. What are your expectations of each user group?

One of the things that impacts ease of use is the complexity involved with composing an alert. Having all the options on a single screen is easier than making users click through a series of screens. You also want to make sure that all the options on this screen are easily understood.

If users will not be launching alerts on a regular basis, the need for an easy-to-use system becomes more important. Choose an application that does not require frequent training to use. Having regular tests or exercises will go a long way towards keeping users proficient with your system.

Administrators

Another important consideration is administration of the application. Ideally, you want an application that can be managed by a user with average skills. You don’t want an application that’s so complex that it requires IT support for management. Involve a future administrator in the review of the candidate applications.

Consider whether your administrators will want to configure the application once and keep the use stable, or whether they are they working in an ever-changing environment where they will they need to spend a great deal of time inside the application. Will IT support be needed or can the application be managed without IT support?


Page 6

Easy to use even when used infrequently.

Different messages to different types of devices.

Alert Invokers

Decide if your alert invokers will be the same as administrators, or if they need a simpler user interface. You need to determine if they can assimilate all the response information in real-time and at varying levels of detail. How expert do they need to be in using the application? You should choose a system that is easy to use even when used infrequently.

Should those invoking the alert be the ones reviewing the output? If not, then make sure the output can be seen in real-time by more than just the invoker.

Mobile apps enable you to launch alerts from the palm of your hand. They are very useful because your staff will not always be in front of a computer. Make sure the mobile app uses alert templates, which reduces the potential for error.

Recipients

For recipients, consider how often they will be responding to the alerts: daily, weekly, monthly or quarterly. How flexible do you need the alert messages to be to cater for different use cases (e.g. emergency versus operational use; or incident response team mobilization versus all-employee duty of care)?

Many vendors offer native mobile applications that work on smartphones and tablets. These mobile apps notify users when an alert is received and give users a better way to respond to the message. Will you want users to have such an app on their devices?

You will probably need to have different messages delivered to different types of devices in the same alert so that you can maximize the value of each device to deliver an appropriate message. Email messages can be of any length, voice messages should be brief and standard SMS text messages are constrained by 160 characters per message. As an example, it may not make sense to send a website address on a phone alert, but it would be useful to have one in an email or SMS.


Page 7

Are features truly necessary to meet a business need?

Going beyond simple emergency notification

Feature CountAre the features you define ones that you need now or will definitely need in the future? Defining too many features that aren’t necessary will likely require too much effort for administration and configuration. Defining too few will lead to user frustration and stakeholder discontent or worse.

Be honest with yourself. Are the features you outline in your requirements truly necessary to meet a business need, or are they “nice to have” features that you’ll never actually use? (Some vendors will try to sell you on slick features that you may never use and which will only confuse users.)

If you’re looking for a highly configurable system, you need to factor in the additional administration effort required to manage the application. If you want to get a streamlined, simple application, what features will you have to live without? Is the compromise worth it?

Would you benefit from a system that offers more than just a standard notification system? For example, some vendors offer incident management applications that are integrated with emergency notification. Also, there are mobile apps that go beyond standard alerts by offering messages with components such as forms, text, photos, documents and GPS location.

Features ListAt the high level, the following features can be the beginning of your list:

• Multi-channel notification (voice, SMS text message, email, native mobile device notification, pager, fax)

• Multi-channel response to received notifications • Multiple response options, not just a simple

acknowledgement• Different messages to each device type in one alert• Recorded voice alerts (this ensures accuracy that might not

be delivered by text-to-speech)• Device categorization (such as home or office phones)


Page 8

Features driven by customer needs.

Consider the applications you need to integrate with.

• Automation rules such as escalation, sequentially contacting people until someone acknowledges and dynamic teams based on roles

• Option for leaving voicemail• International coverage and points of presence• Selecting recipients on a map by drawing shapes to define

location• Send follow-up messages based on initial responses• Target specific locations, such as a campus or specific

buildings• Conference call and contact center bridging• Single web page to launch an alert (for ease of use)• Native mobile apps for launching and responding to alerts• Consistent user interface between administration,

invocation and receiving an alert

You should also have a clear definition of how product features will evolve. This is not so much a list of features in the pipeline, but the process by which new features are identified and incorporated, time-scales between releases, and how specific customer requests are handled.

Future feature enhancements should be driven by customer needs. Make sure you check with the vendors and get examples of how agile they’ve been when working with customers.

Integration with other ApplicationsMany emergency notification system implementations don’t need to integrate with other applications, but the most common point of integration is with a global directory which stores contact data.

• Will you need to integrate with other applications? • How easy will this integration be to develop and configure? • Is an integration necessary or will manual data import be

sufficient?• Do you have a BCM system and do you actually store

contact information that is current within it?


Page 9

Available even when your infrastructure is not functioning.

Successful implementation is an iterative approach.

Partnering... not just handing you a system.

• Should this be the place to gather contact data and teams from, or is the ‘gold’ source somewhere else?

• What about other operational systems such as Physical Security Information Management Systems (PSIMS), supply chain and logistic applications, or help desk systems?

Hosted or On-premiseSoftware as a Service has become customary for notification systems. The extra resiliency provided is often cited as a reason for this. But what does that mean? Essentially, it means greater availability of the application, even when your infrastructure is not functioning.

The vast majority of notification systems are now hosted by the vendor. This is for a number of reasons including internal disaster recovery requirements, sharing of resources, no hardware investment by the customer, and reduced administration overhead.

There may be cases where an on-premise solution is truly required, but these are uncommon. If an on-premise solution is required, ensure that the vendor can recommend suitable resiliency options and show how the primary and back-up systems are going to be kept in sync.

Customer Support and ServiceEffective customer support and service is critical if you are to continually benefit from the investment in the notification system. There should be a clear understanding and a proactive involvement with the vendor to establish short, medium and long-term goals throughout the duration of the contract. Successful implementation is normally an iterative approach, with increasing levels of sophistication reached over the months and years.

Will the vendor work with you as a partner, or do they just hand you a system? Proactive support is the key to good customer service. The vendor should have a complete understanding of your needs, the ability to deploy resources when needed, and contact with the customer on a regular basis.


Page 10

Tease out the approach to resilience.

Resiliency encompasses data integrity and confidentiality.

Behind a proactive approach is reactive support. When a roadblock is reached how does your vendor get around it? They need to be diligent in not just the first interaction, but in all interactions until the problem is resolved. Ask the vendor’s references about their experiences with support.

ResilienceIt is important to know whether there is only a single data center. There is also much discussion about the type of resiliency offered. Rather than asking what the configuration is, there are other questions that will tease out not just the technology, but also the approach to resiliency by the vendor. For instance:

• What happens when a critical failure stops the primary data center?

• How is failover handled and what happens to capacity?• How quickly will the full service be restored?• What happens when there is a software fault or data is

corrupted? • How does the resilient process handle a fault or

corruption—is the problem isolated or propagated around the infrastructure?

Resiliency should also encompass data integrity and confidentiality as well. It’s not just about availability; it includes such topics as information security. Think about your processes and your attitude towards information security. Audit them against your internal requirements so the vendor can show that it can meet the requirement not just now but also into the future.

Vendor TrustWhen you purchase anything, you are buying on trust. A company’s reputation is important in this process. How the vendor treats the customer throughout the buying process is important. Often, what happens in the buying process is reflected, or even amplified, in the implementation and support process. Check this with references. Confirm that previous commitments made by the vendor have been kept.


Page 11

Speed the process and keep the momentum.

SummaryAs in any investment, it is important to understand the business need. This should drive the decision-making process. But don’t think that an exhaustive list of features and rounds of corporate buy-in is the best way forward. Trying to do it in this way will only lead to exhaustion. Try to use a focus group or workshop to speed the process and keep the momentum.

Consider not just functional requirements, but also ease of use, levels of service, trust and reputation. Ensure that your deployment is iterative so that you can increase your maturity and success in a managed and quick manner.

Early wins breed success and fuel demand within the organiza-tion, much more than trying to define everything in advance. Incorporate all these points and your investment in an emergen-cy notification system will yield real benefits and real rewards.

Emergency Notification and Incident Management

Smarter Emergency NotificationThe Notification Center™ is built for mission-critical enterprise use, yet it’s easy to use and manage. Intelligent, customized automation adapts to changing situations and ensures a successful alert. Features that you won’t find in many other systems include device-specific alerts and alerts recorded in your own voice.

Incident Management SimplifiedThe Situation Center™ provides the tools to remedy an incident better and faster—share information, monitor tasks, track people’s status, send alerts, access any type of file, and more. It’s a streamlined virtual command center that enables you to put your plans into action with the click of a button.

Revolutionary Mobile CommunicationEarShot™ goes far beyond ordinary notification. Communicate with rich 2-way messages using text, forms, photos, documents, profiles and GPS location. Increase situational awareness, get on-the-scene intelligence, communicate with field personnel, and much more.

Contact us to learn more or schedule a demonstration.

[email protected]

North America+1 877.833.7763 (toll-free)+1 312.445.8811International+44 203 021 1036

Manage an incident in the palm of your hand

100113

how to choose an emergency notification system

Business

ultimate business needs

unique needs

exact needs

operated system

notification tool

list of requirements

resiliencehaving requirements

features list