If you were talking to someone whose organization is considering Everbridge IT Alerting, what would you say?
How would you rate it and why? Any other tips or advice?
Take your time and look into the total package. There's so much involved in Everbridge. You think it's just alerting but the scheduling package is really phenomenal and the way it integrates. So take your time and look at it thoroughly and learn the bells and whistles before making a decision to know what the whole package is capable of doing. They also have a bridge process where they set up the bridge for you, where you don't have to use something like WebEx. They can do it internally. We didn't know that at the beginning. Look at the package of all the things they do. We're going to integrate it with ServiceNow. That's going to be important. We haven't used single-sign-on with it, but that's something we'll be looking for later and I don't know how good it is. I would like that to work seamlessly. We don't have single-sign-on right now. Each person logs on with their AD account individually when they go into Everbridge. Single-sign-on is available but we weren't focused on that at first. We were focused on getting the alerting system working. Now that we have that working, we're going to go into the next phase of alerting with the calendar and single-sign-on. It will make it easier for people using it to be able to sign on once. We have 450 users on the IT side. Globally, there are 15,000 but we're only in charge of the IT side. There are 1,000 people in IT, but right now 450 are in Everbridge. I would rate Everbridge at ten out of ten.
It is about ensuring that you have the organizational buy-in from the top down. This product starts with the C-level suite when you're going to implement. We struggled through having to prove that the product was worthwhile before we were able to fully implement across the organization. We found some early adopters within those IT responder teams and showed them that this is a product which would help them as well as help our organization. We started out with three or four teams three years ago. Now, it is a standard. The organization realizes that there is value here, and that we are going to continue to use it. We have expanded it to more than 50 IT responder teams across the organization. Now, whenever we find a team who isn't using it, we onboard them pretty quickly, as it is part of the standard. The product is pretty new for them. We were a pretty early adopter to the product. I don't know where we stand in terms of 10th or 50th (or whatever), but I know that the product itself is only about four years old, from what I understand. We have already been able to drive a massive amount of value out of it in its current state. Anything else is what I would call finessing, or refinement. Some of that may be specific to my organization and how we use it. We already have a roadmap of how we will to continue to use it, which will be leveraging a lot more automation, but most of that is already ready on the Everbridge side. It's more our ServiceNow instance that we need to prepare for that level of automation. All of the core function that we are looking for is already there in Everbridge. They have the connectivity into our ServiceNow instance, which is pivotal, so that we can affect workflows to automate our engagements. Today, it's our network operations center and major incident management team who are requesting resources. The intention is to have our ServiceNow instance automatically do that based on defined workflows, so we are taking the human element or delay out of it. Everbridge is already set to allow us to do this. I would give the product a solid nine because of their support. It is how responsive that they have been between their account management, technical resources, and leadership. They knew that we had a very painful implementation the first time. Therefore, for our second implementation, they were very hands-on. We had a lot of conversations leading up to the implementation about the support that we needed and what our goals were. They were very responsive in providing us pretty much whatever we needed, just short of Professional Services and doing it for us. They were very clear that they could do all of this for us but there would be a fee. However, they are always there to help, which is the biggest thing for me. You almost consider them to be more like a partner than a vendor. If you treat them more like a partner, and they treat you as such as well, then you are likely to have a much more desirable outcome.
My chief advice would be to know your use cases. A tool like Everbridge can do just about anything. All of these tools are very powerful tools. Start small, pick something that is attainable and that you can measure, and then build from there. Sometimes people try too hard to do everything at the same time, to implement every possible functionality on day one. It never works. Also, if you have a poorly defined use case you have a problem. The tool itself is good but, while Microsoft Word is a decent tool, it doesn't make me a writer. That's how I see Everbridge. It's a decent tool, but it doesn't mean that it makes you an alerting god if you don't know how you want to use it and how you plan to use it or what your expected results are. You really have to think through the process, the whole process. We're lucky that our incident management processes were defined. People knew what to expect. I had some very specific use cases. I needed shifts, I needed rotations, I needed device discrimination, depending on the type of alert. I needed targeted escalations. I needed escalations to our NOC for certain types of events. All of these things had to be figured out beforehand. If you discover them as you go along, it impacts the design. If you're designing for a fuzzy need you're going to have a bad time when it comes down to implementation. In terms of improvement in remediation time, we had already seen that. Our use case was the same use case we had before. It was the primary means of notification for our ticketing system. In terms of incidents coming from automation, from monitoring, in any given month there would be 6,000 to 10,000 tickets, depending on the month and what happened. Something to know about these systems is that once they're configured, they're pretty much set-and-forget. After that, it's just add a user, remove a user. It's very rare in our specific use case that we'd have to change a template. In terms of IT alerting, I'd give Everbridge a solid eight out of ten. I'd give it a nine if the subscription functionality was a bit better. It's lightweight from an end-user perspective. It's not overly busy. It's straightforward in the way it communicates and it's heavily customizable.
My advice would be: Do your homework. It's a matter of looking at your specific needs. To me, it's like buying a car, it's the fundamentals of the system. Does it do what you need it to do, what's important to you? And look at what the future capabilities of the system are. That's part of it as well. My team, IT, uses the system on a day-to-day basis and the others who use it are the developers on the ticketing-system side. Our team is using it for IT support and I have about 50 or 60 individuals who are working in the system and using the integration, 24/7 and 365. But there are other slices of our organization, which are not IT, that are using it for communication. There's Customer Operations and Field Operations and others that are also using it for similar purposes but different use cases. In terms of usage, it's integral. We use it many times every day, all day. The various organizations within the company are using it every day for communication and coordination. There are other integration possibilities in some of the existing features that we're not taking advantage of. And in the future state of the platform, there are some interesting possibilities that I see with integration with our monitoring tools and some of our other services and applications. Everything really seems to integrate pretty well. The support from Everbridge is really excellent. When we want changes or we need improvements, we get those fairly quickly and they're very communicative with regard to the product's platform itself and the enhancements. They seem to be looking very intently at the future to see the space grow and what it's going to evolve into. They're doing a pretty good job with that. They have helped us with some of the moving parts of the integration with the ticketing system. There are enhancements we wanted with the mobile app, any number of changes with integrations and APIs. We've actually had a lot of improvements to it, even in the last year since we deployed it. I would rate it a good, solid eight out ten. I'm not going to give anything a ten ever. There is some room to improve the initial-rollout functions which are a little bit painful.
Get that executive leadership backing, and make sure that you're not just going to use Everbridge to page out to people in a different manner. You should look to set that "timer" pretty low on bridge engagement and get people used to responding and getting on bridge calls immediately, because every minute of an outage is lost money. Determine up front if you are going to do the group integration from whatever application you might be looking to do the user-sync with. If you are going to have an application with on-call schedules maintained, such as Service Now - as I believe there is an option to turn on group sync - be careful about turning that group sync feature on. User sync is pretty straightforward but we were warned against using the group sync feature for various reasons, even from within Everbridge. Our users are support staff, on-call resources, on-call leaders, incident commanders, communication managers. There are a couple of senior leaders who know how to use it, but it is mainly incident management and communication management. Our deployment team was just a handful of folks. We needed a little bit of partnership from our ServiceNow folks to get the API into place. You could go with a half-dozen people on the integration. For the maintenance aspect, it's even less than that. There are four of us who administrate the tool. I'm the communication management piece of it. My manager handles major incident and critical communications, so he's incident management as well, and he does a lot of admin work in it. Our project manager is the incident commander and communication management. We have support staff who don't have the rights to kick off Everbridge to automatically engage people, but they'll still access the Everbridge Member Portal to manually look up resources and call them for lower-priority issues. We use it pretty heavily right now and we are definitely looking at other ways of utilizing the tool. We expect it to increase pretty substantially, as we go forward. One of the big things that we're looking to do is integrating it with event monitoring. We're looking to further reduce the mean time to assemble for major incidents by bypassing the current process. Currently, event monitoring takes in a ticket and it gets assigned to a queue in ServiceNow where an agent will see it, and they'll call out the support person. That person will say, "Okay, well we need a bridge call for this." What we are trying to do is identify, with the various application support teams, among the events that are creating tickets, which ones are deemed "critical" that could be a precursor to a major incident. We want to identify those and create incident conditions in ServiceNow that will engage an Everbridge template to get the incident management team engaged right away, rather than waiting on those manual actions to happen. We're still in the early stages of that, and we are looking to increase that sort of usage for Everbridge to gain more efficiencies. Some of them are live right now. We call them the "Everbridge critical alerts" and we have many that are already in production. We are looking to expand that even more. I would rate Everbridge IT Alerting at eight out of ten, overall. It's a very powerful tool. We've made a lot of efficiency gains but there are definitely things that, from an enhancement standpoint, we would like to see added to the tool. The progress on that hasn't been as quick as we'd like. Its been pretty slow going. With what we already have in place, it's enabling us to do a lot. I absolutely love having the tool. I would not rate it as a ten out of ten, but they're definitely heading in the right direction. From what I've seen, as far as what they are planning on having, I would say it could be a ten out of ten this time next year, if things go well in year-two. But for year-one, I would say it's an eight out of ten.
My advice is to leverage any of the integrations you can. In addition, do the prep work, including creating contacts, users, and groups, prior to the consultative work provided by Everbridge. We have over 500 users, a majority of whom are group managers along with some organizational and account admins. We have two FTEs supporting Everbridge and their roles range from configuration management, to vision and strategy, and vendor relations. The product is used extensively, with roughly 25,000 messages sent through the tool annually.
It is the best tool that I have ever used.
Dig into the resources they have, like Everbridge University. Don't rely completely on the on-site training because it's only one day. The best way to learn is by doing. You need to get in there, push the buttons, pull the triggers, etc. My advice would be, when they turn it on, get in there and put in a couple of contacts and start sending messages, to get used to the interface. Take their online stuff, use all the resources they give you. Don't just rely on that one day of on-site training they provide, that's not going to do it for you. You can go into Everbridge University and type in, "I want to know how to do 'x'," and there will be modules on how to do that. You can watch the courses and it gives you enough to get in there and start figuring it out. There is also an interactive user community. We haven't gotten much into the API stuff. We need to. We're starting to use scheduling a little more. With our police and fire department and the air-com staff, the staff that I manage, we're trying to get more people involved with it. Because the scheduling is its own thing and it doesn't integrate with how they schedule their staff, it's been a little difficult getting them to stand that up. But that's more just trying to find someone there who is willing to keep that schedule in Everbridge up to date so we can make sure we're not waking up people who shouldn't be woken, and that we're alerting the people who need to know. That's what we're focusing on now. We like it. It works great. If you ask the dispatchers who do 90 percent of the launches, it's leaps and bounds better than what we were doing before. Back then, they were having to call in and type in all these codes and verbalize the messages. If they misspoke they had to hang up and start over. It was a giant pain. With Everbridge, it's just fill out the form. If "x" is happening you click on that form, you fill it out and hit Go and it goes. You don't have to worry about whether the right person will get it because that's all been pre-programmed. They really like the ease of use. This has been one of the better products that you buy off the shelf because it just works. With almost everything you buy that requires as much customization as something like this does, you're going to have problems, but we've had very few with Everbridge. It just works.
Prepare ahead of time with your vision of what you want from it. We were able to start implementing the tool on the very first visit with our account representative, saving time and money.
I am pretty happy with the way it works. We are very happy with it. We have not made changes to it because it just works. It does what it says it does. The application works. They have a long history, but the system is advanced and modern. It has a lot of great features and they keep adding to it.
Scope the project well. What I mean by that is, don't bite off more than you can chew, but don't do less than you need to do. Scoping it well means that you've identified the happy medium of, "I'm going to get great value to start, but I'm going to get more value as we continue to grow into the solution." That's the approach we took. We said, "Hey, if I can get the 80/20 rule applied, where 80 percent of what we're expecting to get out of the gate is achievable in our first deployment, that's pretty solid." If the other 20 percent isn't crucial - figure out how to prioritize what you do need and what you don't need - it's okay to let it go. Part of what we saw with our own project was the danger of scope-creep, where we said, "If our first objective is a like-for-like replacement of the incumbent, then be prepared to sacrifice some golden opportunities if those golden opportunities will cost us time and money that we don't have right now." If we said, "Implementation date is an important milestone and cost of implementing is an important measurement," then I need to measure inside of those scoping guardrails. Don't do more than you can handle, but don't do less than what you need. I think we accomplished that pretty well. I think we sacrificed a couple things that several of our stakeholders would have loved to see out of the gate, but it would have cost us time and money that we weren't really prepared to spend. I would start out with rating this product at eight out of 10 because there is always room to improve. I'm not sure I'd rate anybody a 10. I've been in this for a long, long time. I don't know that I've ever seen a true knock-your-socks-off 10. But this solution is a solid eight in that they provide the core functionality we were always interested in obtaining, and they are very engaged at the table in discussing how they get better and how their getting better can help us get better.