This posting is part two in a series of discussions on what to look for in a notification system. Part one can be found here. Please weigh in with your experiences – have you recently purchased a system? What do you know now that you wish you had known then?
If you are currently in the market for an incident notification system, where do you really start? What should you consider? Let’s continue the discussion with another five things you should be considering when you dive into your search process.
6. What type of architecture do I need? There are four basic architecture types: Premise, where you you buy and host the solution; Hosted, where you subscribe to the solution, but it is hosted by a third party; Hybrid, where you buy the solution and the hosting rests with you and the third party vendor; and finally SaaS, where you subscribe to the solution and the vendor hosts. Knowing which you prefer will help your search process.
7. Does the vendor own their own architecture? Many vendors sell other vendor’s notification systems. Sometimes this happens many times down the line. How do you make sure you get the best customer support in this situation? How are your customization requests implemented if your vendor is not in control of the system you have purchased?
8. Do they do their own development work? If a vendor has outsourced development, the question is, how virtual is the development and support staff? How does this impact turnaround times? Outsourced development can add hours to your requests.
9. Is it a shared or dedicated hardware environment? Dedicated hardware environments have higher upfront costs and mean some additional questions – for example, is the hardware real or virtual? Is the environment a truly dedicated one? How is site redundancy accomplished? Shared hardware environments have lower upfront costs, while the server and site redundancy is simplified and robust.
10. How does the vendor handle redundancy? How does the vendor handle network and server redundancy? How long does it take to fail-over when any component fails? What single points of failure exist, if any? What level of uptime do they promise and and what have they delivered? In an emergency, the availability of your data is a necessity and an urgent one at that.
Were any of these considerations a part of your search for a notification vendor? If so (or if not), did they become a factor in your experience with that vendor?
Come back to the Everbridge blog for the next installment of this thought-provoking list of tips to help you select the best notification vendor!