Everbridge IT Alerting Reviews

We use it to alert management of priority-one incidents. The company uses it for global incidents but we have a subset of it for priority-one incidents, to let IT management know what is going on and so IT knows it's priority-one. The future is to let them know about priority-ones, twos, and threes, for the on-call schedule. But right now we're in the priority-one stage.

For the P1s especially, we had a lot of incidents where we got notifications that things were going down, and just the time it took to get people on the call - the bridge - and to get people to respond sometimes took as much as half-an-hour or 45 minutes. Now it's really down to 15 to 20 minutes. So the response time in getting teams together is much better, much more effective.

At this stage, which is step one - and we're going to try to get better - we have incidents once a week. On each of those incidents we have to do calls on root analysis and why it happened. From that standpoint, we get people on a call much faster to get it resolved much faster. In turn, the calls are becoming less and less. We're down to once a week. We want to get down to once a month.

A better response time helps you learn what's going on and how to prepare for the next time. For example, knowing that in January we had an incident where Asia/Far East went down because the things we were doing at night caused that slowness and lag time, we realized that we if changed things that we do at night in America, we wouldn't have the lag time going on in Asia. We realized that the things we were doing in America were affecting the next day in Asia.

It helps us get everybody involved, the first, the second, and treasury, where normally, to get even one person on the line was difficult. I work at night, from 7:00 PM to 7:00 AM, and that's the hardest time to get somebody on the line and get them actively involved. But they know that when they get that call from Everbridge - and if they don't answer it goes to their home phone, it goes to their cell phone - it is important that they get on. It's not just a call for general information. They know if it's an Everbridge call that it's something very important and that their manager is looking at it. That puts us in a better place. When there is a call, they respond.

For us, the most valuable features are the alerting and messaging, SMS messaging and text. We have a 15-minute window to get everything out and open, and without Everbridge we would never make that 15 minutes. Just the fact of who it alerts, and how it gets them on calls, is amazing.

The scheduling calendar is also very helpful and very useful. That's what we're looking to roll out. We have other incidents where we need to get people who are on-call to respond back to us and it's a very manual process right now. We call a person and keep trying until we get them. When we get this feature working in phase two, it will reach out to them and if it doesn't reach the first person it will reach out to the next one. The third call will go to the manager to let the manager know that the first ones haven't answered.

It's very customizable. For instance, if you're going on vacation this week, you go to your calendar and say, "I'm off this week, make the secondary the primary." And that's done on-the-fly. It's very responsive. It's very user-friendly. The guys don't have much training in Everbridge but they know how to go into the calendar, move their name out and move the next person up. It's very good.

The calendar is very dynamic. We use ServiceNow which has a calendar-based program, like Everbridge, but the two are night and day. Everything that I've been diving into with Everbridge is actually better than the products we have out-of-the-box. The calendar in Everbridge is much better. Your contact list is already there and that makes it customizable. With ServiceNow, it's very clunky. It's not intuitive and it's nowhere near as dynamic.

What I would like to see is vendor alerting. It's not structured to take into account that users outside of our environment, users outside of IT, may not be in the group. IBM is an outside vendor for us, and we have IBM CEs who come in on a regular basis. If there's a problem, we call those vendors in. That should be tied into the system where we can say that vendors A, B, and C have these users and we want them available to come into the office when there's an issue. We want to be able to alert them in the same way we alert internally. If this contact is not available it would move to the next and the next. It would be great if it could do that.

We have tons of vendors we use from outside of our organization that are not part of the contact list, they're not users in the firm. But if they could be a "vendor contact" and we could scale it the same way we do with individual employees, that would really be the icing on the cake.

It's very stable. We haven't had any problems with the system at all: Getting it in, being able to launch it from mobile devices, from inside the office, outside, websites. Everywhere we go to get into it, it works seamlessly. There has been no downtime so far.

For us, the scalability is great. We're going to go larger later on, but right now it's working for us. On our scale it does 1,000 of us in IT and for that it works perfectly. As we get bigger and push it out more to more users, we'll find out more about the scalability.

We used their consultant, Brandy, in the beginning. Then we started using technical support for lockout issues. What happens a lot of the time is that when you send out an invite to someone to join, they get the invite and wait too long and then the invite expires so they call tech support to get that refreshed. Tech support has been very friendly, very knowledgeable. Aside from lockout issues, we've contacted them for password expiration, for users wanting the Evergreen app for mobile. Some of them can't have it, some can, depending on who they are.

In terms of the lockout, it's fine because you get three attempts to log in and then you get locked out. It changes every 90 days and that's fine for us. That's what we do with corporate, so users are used to it. But that's why we're going to go to single-sign-on, so they don't have to remember that many passwords. When we get there we'll probably alleviate this problem.

Once our people are up to speed with it, they will be able to do it themselves. 

This is our first time using this kind of solution. We were doing it manually before. We were sending out emails and WebEx conferences manually.

In our case, it was taking what we had - because we were using it globally - and making a subset for us for alerting. The Everbridge consultant did it seamlessly. In the first meeting she set up the organization, put us in and gave us admin rights. They did most of the work. The only thing we did was add the contacts. That was manual but not complicated at all.

It took us a week to get the contacts in and the full deployment was done in two weeks easily, including testing and having users going.

The implementation strategy was designed by Everbridge. We thought we could go in and go straight to step one. But there was a lot more design to it. We had to set up the clients first, do the consulting stage, and then worry about how we were going to make a template. We thought it was going to be quick and dirty, but there was actually more of a learning curve for us. We had to set up templates first, learn how to change templates and make templates our own so that, in the future, we wouldn't have to go back and get more training. Instead of turning it around in a week, it took us a month because we wanted to be thoroughly trained in it. Now we do all our own templates, we do our own calls, we do our own updates, we do our own contacts. The month was really good for us. It was slower than we expected, but it really helped us out.

It could have been faster if we wanted things out-of-the-box. It could have been much faster. But we took the initial steps at that time to learn as much as we could so we would be independent. Now we have a much better understanding of what Everbridge does. That time was really important because we also trained our staff. The time was well spent.

Everbridge had an implementation team that worked with our company before our team was in, to set up the national implementation. Then Brandy, from Everbridge, worked with us. We had the day shift which was two supervisors, another two supervisors at night, and two managers. So it was done with a total of six on our side. Those six people are the ones who maintain it.

We worked with one of the Everbridge consultants and she was very helpful. 

Our ROI is in the response time. We have a 15-minute SLA that we were never meeting. We were physically not capable of meeting it in a manual environment. We thought it was unheard of to hit that 15 minutes. Everbridge makes it possible. From where we stood, we thought we'd never get to a half-hour SLA. Today it's 15 minutes.

As far as I'm aware, there are no costs beyond the standard licensing fees.

There were other options we were looking into besides this. We thought another one we looked into was going to do it, but its alerting system didn't do it. Our new manager came in and had his own options but he never showed us what they were because we were so far ahead with Everbridge.

The main deciding factor for going with Everbridge was the integration we're planning to do with ServiceNow. We knew that we wanted it to work with ServiceNow. From a ticketing standpoint, we have tickets that can now be created in ServiceNow that work with Everbridge. So if something happens it will assign an incident number to Everbridge, and we won't have to do that manually. We were also looking at replacing WhatsUp Gold. The new processes coming into place that should work well with Everbridge also.

The competitors had the same features but I think Everbridge works better because that's what they do. Everbridge is an alerting package so it's more robust.

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.

We have a ticketing system, Remedy OnDemand, a fairly large IT shop, several thousand servers, about 900 people or so working in IT, about one-third of them are doing support in one way or another or having to deal with incidents. So the use case for this tool was to notify teams or individuals that there was an incident in progress that they needed to attend to. Usually, it was for incidents that had the kind of priority that needed immediate attention.

Natively, Remedy will send out an email. But if you need to get somebody's attention because a server is on the brink of falling over, that doesn't cut it.

Our use case was essentially incident notification.

I was there to transition to the tool. I did all the use cases for it and then I handed off the reins of power to my successor.

For us, having a quick response to urgent events - events that were not necessarily critical but that could become critical if not dealt with urgently - was important for us.

Prior to having a notification system in place, we either had to have an operations person checking all the queues in Remedy or someone subscribing to emails from Remedy and then doing manual call-outs to people at 3 am because a server died.

We had a fairly sophisticated ticket flow. We had a monitoring system with an events co-relation and event management system that would then automatically create incident tickets. The incidents tickets, based on their level of urgency, would then be channeled out through the Everbridge IT alerting platform which would then trigger off escalations based on the urgency of the incident. For example, if there was a P1 incident where the data center was down, it would escalate much more quickly than if there was a P3 issue that you needed to look at quickly to avoid a P1.

If we were to compare no IT alerting to IT alerting of any kind, the latter makes a significant difference. In our case, we used to have real, live operators who would call people out. Now, the operations staff is there just to manage some escalations but it really removes the human from the equation, from the moment of detection to notification. 

Before, we'd have a human looking at a console of some kind and that person would then have to look up a contact list to find out who was the owner of the alert, find their number, call them and, if nothing happened, figure it out, and say, "Okay, I've got to escalate." They would then have to call the second person in line, and so on. It was not really a manageable situation. Having an alerting solution connected to our ticketing system made the flow much more effective and really did improve our overall response time and uptime.

There are quite a few valuable features. In terms of the general notifications, one of the things that was interesting and good is that you can configure the tool to escalate if no action is taken within a certain time period. That avoids sending off an alert that nobody deals with and where nobody knows that nobody has dealt with it. 

You can program in rotations, shifts, and scenarios of different kinds and it allows you to page multiple people, or people in sequence, or a group of people simultaneously.

Another good feature Everbridge has is deduplication. We had cases where everybody on a team had the same phone number. Maybe they were passing a cell phone around. When the tool sees that, it doesn't call the same phone number 15 times. It will call it one time, because it will see, as part of the list of devices and device hours, that it's a duplicate.

Once your users are defined, you can pop up a map and draw a circle on the map and notify everybody within that area. That geo feature is really useful if you have a particular incident where there is a protest on the street, a building on fire, a Hazmat spill. These are all scenarios that I've lived through.
It was crucial at that time to have a solution where one could say, "Let me draw a radius around the impacted building and have everybody in that radius contacted." That was a huge win.

The feature that xMatters has that Everbridge doesn't have, or has in a limited way, is a method of funneling some alerts, as an FYI, to other stakeholders who are not necessarily prime actors in an incident. For example, you have a support team that supports critical application X, and you have somebody who is actually the application owner. The application owner normally does not normally get called out in the middle of the night to let him know that his application is down, unless it's super-critical and it's going to stay down. But they would be receiving a copy of the notification that was sent out so they'd know that something happened overnight, or that something is happening right now.

It's been performing like a champ. We haven't had any outages. I had lunch with my buddies last week, and there has been nothing significantly wrong. It's been flowing like it should. 

The old 2012 solution was using somewhat dated technology and it was starting to choke on a regular basis. We really didn't want that with the volume of incidence tickets that we were generating.

We didn't have any scalability issues with it. I don't have a comparison point, but it easily handled everything we threw at it.

Everbridge's tech support was really excellent. They were on the ball, they had answers to our questions. They made things happen that they probably hadn't done beforehand. I found them really collaborative and very much a pleasure to work with.

I found Everbridge to be very responsive during the implementation phase, and post-implementation, whenever we had questions, we were able to reach out either via our managed service provider or directly to Everbridge. As a longtime tech guy - I've got over 30 years in the business - they were really a blast to work with. It's always great to work with people who are competent and who have some kind of empathy for your reality.

I'm not sure if I was dealing with US people, Toronto people, or overseas people. There were a lot of people from different places coming onto phone bridges. At a certain point it was hard to tell who was a managed service provider, who was Remedy, who was Everbridge. It was just quite the multinational effort.

It could have been a real horror story, and it turned out very well. We were starting to have doubts at one point, and then they called in the cavalry. We had a few extra resources. And things went off pretty much without a hitch.

Before, we were using xMatters, which is another notification tool, a very old version that was resold to us through a managed service provider. Our xMatters solution was hosted by them and it was at end-of-life. It was the last xMatters on-prem offering back in 2012 or 2013.

When we migrated we looked at different solutions but the Everbridge solution was the most cost-effective at the time. It didn't have, from my perspective, any other clear advantages over xMatters, over PagerDuty.

In our environment it made financial sense and, with the templates, it made operational sense. It worked just fine. It was surprisingly, blazingly fast. The throughput was pretty incredible. The time from when the incident system - the ticketing system - poked Everbridge to say that there was something going on, until Everbridge starting to notify, was very short.

I wasn't even aware that Everbridge was doing an IT alerting product up until last year. I had always known them to be a mass-notification type of company. It was actually a smart move on their part to leverage their mass-notification capability - which, by definition, means you're alerting a whole ton of people in a very short period of time - into an IT alerting product.

In the past, that's where we would run into issues with our on-prem xMatters installation. Sometimes, when there were too many alerts, a lot of queuing would happen. I didn't see any instances while I was there - and we did tests with a lot of events - of much queuing happening on the Everbridge side.

I don't really consider Everbridge to be a relatively new product. Everbridge had an alerting product beforehand. All they did was enhance their alerting product and add functionality required for it to become an IT alerting product. But they started off with a really good base. They managed the transition to an IT-alerting product fairly gracefully.

The setup was straightforward once you understood that it is a different paradigm. When you're used to things being a certain way - if you're used to Windows and you switch to Mac you have a little bit of an adjustment period and then things become intuitive. It was the same here. There's nothing inherently overly-complex about the tool itself. But if you're coming from another tool with a different underlying paradigm, you do have to wrap your head around some different concepts. It took a while to catch on to how to properly use the tool and to convey to Everbridge what exactly we were expecting as a result.

The deployment took about two months.

There were a lot of steps in there including a massive cleanup of the old notification system, so we wouldn't transport garbage into the future, a migration of over 1,000 users, which is quite a bit, all the technical onboarding that had to happen for people, so that they'd know how to use the new tool, exposure to the new functionalities. The training was done simultaneously with the integration of the tool. We had a Dev, a QA, and a Prod environment. We ran it through its paces in all three to make sure it worked out. 

The project took longer because the biggest problem was deciding on the tool. But once the tool was decided on, it was about a two-month effort to convert.

 The actual technical implementation strategy was really just making sure we were passing the right variables and tweaking templates until they were just so.

We used our managed service provider, and we had people from Everbridge and Remedy directly involved. But we did not have any third-party consultants.

Considering the knowledge of the people who were involved in the implementation from the Everbridge side, the transparency with which they worked with us, and the rapidity of the responses and corrections or modifications or tweaks, it was really a very pleasant experience.

It replaced something that was already doing a very similar job, so the ROI is hard to quantify. We already had something that notified people. Compared to having nothing, the ROI would have been substantial.

But let's look at it this way: If you have 1,000 users and you're paying $25 a head, you're paying $25,000 per month. If you have access to metrics on incident management and how much it costs a large organization to deal with a major incident, having a notification tool in place reduced our number of major incidents by about 20 percent, year over year.

It's helpful when you can notify and have solid proof of notification. Then you have accountability. What was particularly interesting was that the gains were seen because people were then able to be notified of things that were urgent but not a P1 yet, still at a pre-impact level. The classic example would be a disk that is filling up. You've got a critical app and if the disk fills up, you're toast. Monitoring picks it up, creates a ticket, dispatches it off to a team, the team gets notified. If nobody responds within 10 or 15 minutes, it gets escalated. So for sure, within half an hour, somebody would look at it. Just doing that greatly reduced the number of disk-space incidents we had.

In terms of additional costs, I was just the guy who was the pain in the back, telling them, "No, we need this functionality. You forgot this. These are the use cases that need to be represented." But apart from the integration costs and, obviously, using resources from Remedy and using resources from Everbridge, regarding licensing costs we just had that flat fee. Once we integrated it was just a standardized fee.

Our need was very unsophisticated in the sense that we wanted to notify a predefined set of people based on predefined criteria. Within Everbridge you could accomplish that using something called templates. It had an automated flow-through.

What xMatters has that Everbr201ge e doesn't have is something interesting called a subscription, where you can get an FYI notification of an event or incident based on matching keywords or other elements of the message.

We did a quick market scan and we saw PagerDuty out there, xMatters was out there. I don't remember if there Opsgenie was available at the time. But there were a bunch of them that all seemed to coalesce around the same price point and, for whatever reason, Everbridge came in as less expensive and they did integrations with Remedy OnDemand.

That was good for us because in a large shop with a good flow of incident tickets, for the people who are resolving these things it becomes cumbersome to take notifications, log in, go into the ticketing system and assign the ticket to themselves, and then work on the problem. With the Everbridge integration the person who acts on the alert becomes the owner of the ticket and the ticket changes status. That facilitated the visibility of how the incidents were being handled at the bank.

We also needed device discrimination based on severity of ticket, time discrimination based on the severity of ticket, and impact of ticket. You're not going to page out somebody for a low-level event.

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.

It is for our Global Security Operations Center (GSOC). We use it for its functionalities. It is a part of our alerting systems. Because it's a global company, we have a GSOC and some of the functionalities that we use it for are tracking security threats, monitoring, and notifying our staff and contractors. We also use it for emergency response usage.

The product started off on-premise, then was migrated to a Software as a Service (SaaS) infrastructure.

We are in the process of automating a lot of our processes. Because it has a SaaS version, the APIs are easily integratable, and we are able to consolidate functions and vendors. This saves money, because of the downturn in the industry, as everybody is penny-pinching these days. We are able to find ways to cut back. This product is very helpful with that since it is a good tool for consolidating functions for security purposes and all of the security functions that the GSOC needs.

• It is easy to integrate. APIs connect to it. Because it is easily integratable with other software that we use, even homegrown, it does save money.
• With SaaS, we can implement in other regions without having to physically go to there.
• We monitor all our security threats globally on our big video wall, which is great visually. 
• The response time is real-time alerting. It is very helpful, because it makes things a lot easier. All we have to do is put a circle around a geo-fence and shoot off a message. For vessel support, they can be notified if there is inclement weather close by.
• We are able to do incident messaging for emergency notifications. We are able to monitor our security alerts. We are able to link all of these functions together. 

I would like them to add GPS going forward. I think they may be working on this, but it is not implemented yet. We want to be able track our shipments, people, and every asset in real-time. With global positioning, especially in oil and gas, we might have a fleet in a pirated area (with active shooters) and have to move fast in situations. We need to know where our people are, how to locate all our assets, and secure them, regardless if they're people, places, vessels, or structures.

The company would also like to have super detailed analytics, as we integrate this with our security software, e.g., camera systems. We want to see ant walking on the ground type of detail. That is the pinpoint analysis that we are looking for in this solution.

The stability is good. Right now, it is a great product. We are just trying to enhance and automate it as much as we can. 

Scalability is pretty good. We haven't had any issues.

Our GSOC is using it right now, which is give or take 20 people. However, it rotates and shifts personnel, so they are not using it all at once.

It probably took a few months to deploy because we go through tests and configurations before going live. We have to test it out in different environments.

This product has helped us save $200,000 from being able to get rid of vendors and consolidate functionalities to doing incident reporting. 

We use it to consolidate and remove a lot of manual processes from the enterprise notification space.

What it allows us to do is integrate with our CMDB. Within our CMDB, we have everything including the ownership, from the executive level down to operational. It enables us to quickly and easily identify who the target audience is through the subscription model that is embedded in Everbridge. It helps with targeted communication and accuracy and timeliness. On average, it saves us roughly five to seven minutes, when we compare all of the manual processes we used to have versus using the tool as integrated into our ticketing system. We send about 15 to 20 of these broadcast messages per day, on average. So the time savings are definitely substantial.

The most important feature, from our perspective, is the integration with our ticketing system. That eliminates wasted motion and time in drafting and sending and finding the right distribution list. It's all integrated with the ticketing system, so from the ticket itself, we manage all of the notifications that we send. We're able to manage an incident within the confines of the ticketing system at something like 70 to 80 percent accuracy. The integration feature with the ticketing system is of extreme value.

Everything could always be a little bit easier, a little bit faster, but I'm not sure that I can really name anything else off the top of my head.

We haven't had any downtime-type problems. At some time within this calendar year, there was a temporary outage for a few minutes of some function within the system, and I'm not even sure it was one that I leverage. I get notifications from them through their communication systems telling me what the statuses are of the various components of the system, and I don't recall any point where the system was unavailable in its entirety. The stability has been excellent.

Scalability seems to be very robust. When I look at not just what we're doing with it but what it can do, if we were to put the proper amount of effort behind some of the integrations, the scalability is good.

I'm looking at changing a number of things in 2019 and there will be opportunities for more integrations so that we take better advantage of the platform. From a scalability standpoint, that headroom is there. It is just up to us to identify those opportunities and take advantage of them.

Everbridge's tech support is amazing. I've been in IT for the last 20 years and I've had a lot of interaction with a lot of vendors for a lot of reasons. The Everbridge team is head-and-shoulders above virtually all of them. Their technical account manager is nothing short of amazing. They spend the time to build the relationships, which I really like. They visit every so often, we have quarterly meetings, we have weekly meetings. They're very responsive. They're really fantastic in that way.

That can be the most valuable aspect of choosing a vendor. The fact of the matter is that you can use a lot of different systems. There is always competition out there. Some do some things better than others and there are little nuances to all the systems. But at the end the day, personally, I'm not a transactional person. I like to build those relationships and build on them and I think that shows in the platform.

We had a conglomeration of a number of tools that were similar in that space but they were not being used anywhere near the way we're using Everbridge now. They were mostly for disaster-recovery types of functions. But we did not use them anywhere near to the same extent as we are now using IT Alerting. We eliminated all of those tools, as far as I know. Some of them were homegrown escalation and on-call type tools. Some were third-party competitors to Everbridge, and we eliminated all of those and consolidated on this platform.

The need for an improvement over what we had was self-evident for an operations person: What was efficient and what wasn't. We could see, fairly easily, what was taking more time than it should. If you're technologically savvy and you know what an automation opportunity looks like, it presents itself.

The initial setup was more complex than I anticipated. Initially, we were using their UI to send our notifications. It wasn't quite integrated with the ticketing system yet, not at phase one. Phase two was the integration with the ticketing system. All of the required data integrations and the normalizing of the data and customizing it for our needs and purposes took more time than I anticipated. Perhaps that was just me, but I was anticipating that it would be a little bit less difficult than it turned out to be.

From phase one where we were using their UI, until we had phase two, which was the initial deployment with the ticketing system, it took about three to four months.

Our implementation strategy was to take a phased approach to get us to our end goal with the integration and our notifications. We had specific business goals: the original deployment, the creation of the templates, and the basic operating model of the system, through to the integration and, now, to the improvements that are in the future-state of the platform. Next is leveraging some of the features within the system that are more intelligent. For example, when you send a notification you could have it posted to the application. There are a whole bunch of more advanced functions that we're still working towards.

One of the other problems we had, which we did not anticipate, was: If we send out a notification to everybody in the enterprise, that's a significant number and, technically, those messages source from "not your domain." There had to be some fine-tuning to make that work in light of things like the spam, IronPorts, etc. on the front-end servers, the mail servers. It took a little bit of work to get that the way we needed it to be.

Including the developers on the ticketing-system side, the deployment took six to eight people on our side. They made the majority of the decisions and handled the testing and implementation. The phase we're in now is more of a business-as-usual release cycle and enhancement type phase. It doesn't require the density of attention that it did.

We used the Everbridge TAM for most of it and then our own ticketing-system people and our own resources.

We definitely have seen ROI. When we have an incident or an outage, we can focus on what we need to do, which is fix the problem, instead of finding forms and sending emails and cobbling together inefficient manual processes. The ROI is clearly there.

We looked at xMatters and at Send Word Now. We also did an internal proof of concept to spec out what it would cost to develop our own system and run it, but for the cost we were looking at to develop it and implement it and run it on a daily basis, it was more cost-effective to use a third party.

This was something that I had actually been working on for a number of years before we adopted Everbridge. I had any number of sessions with some of my operations partners in the company where we would sit down and do a bake-off among those competing tools. As I said, there are nuances to everything, but at the end of the day, we decided we like the Everbridge user interface better. There were some other smaller decision points. Some of it was around cost, but ultimately it was the user interface. And certainly, some of it was due to the people at Everbridge. They were excellent.

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.

We use it for technical engagement and stakeholder communication during major IT outages.

It has made the technical engagement process more efficient, going from approximately five minutes to generate a page down to 30 seconds.

The most valuable feature is automated escalation, as it eliminates a manual process which is prone to errors.

The integration with other solutions needs improvement. I am not at liberty to share the name of the application/vendor we are trying to integrate with, but I can tell you that it is our incident management tool. Due to issues with the libraries provided by Everbridge, we have not been able to integrate IT Alerting with that tool.

Everbridge has been able to deliver in accordance with their SLAs.

Scaling can be a tedious endeavor if users and contacts are manually created.

The technical support is excellent. They routinely answer problems on the first call.

I’m not at liberty to name it but, the previous solution required us to manually look up and engage. This was time-consuming and prone to errors. Those are the reasons we switched.

The initial setup was straightforward as we had a consultant with us. The consultant was helpful. There was a lot of prep work that we could and should have completed prior to the consultant arriving onsite. Had we known to do this, it would have made the engagement more productive.

The deployment took approximately two weeks. Our goal was to configure the teams we engage most often. Those 30 teams represent 95 percent of our volume.

A consultant was used, and the experience was very positive.

The current pricing model is adequate. We feel that the pricing model for our IT Alerting solution is competitive with similar solutions on the market.

We did evaluate other options but I'm not at liberty to comment on them.

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.

Our use case is using it to reduce the time to assemble everyone, especially when reacting to major incidents, and to reduce the time spent doing manual call-outs and engagements in the course of them.

The background, and why we looked into getting a tool in the first place, is that when we were engaged on an incident and it rose in severity or the scope of impact broadened, there were many different checkboxes that we could check: "Okay, now we need to re-engage this person, this person, and this person." Also, just in the average incident-information process, we needed additional speed in getting people engaged, rather than manually looking up the on-call information to see who's engaged or on-call. We would have to manually call them and possibly get voicemail and have to try the second number.

We use it for every bridge call that we host and every engagement of an on-call group that we need. We use it multiple times a day, every day.

Our performance showed us that, for major incidents, we spent over 40 minutes just making manual call-outs. That is why we implement the tool in the first place and that time has been cut down to two or three minutes. We've had tremendous gains on that.

It's a lot easier to create and manage schedules, especially in comparison to the on-call scheduling creation in ServiceNow. That has always been something of a bear to operate. We've found it's a lot simpler in Everbridge.

It enables everybody on our team to focus on their primary responsibilities, driving toward restoration, instead of being distracted by manually calling folks.

Creating the templates and being able to create my own variables are helpful features.

Their latest features are going to allow me to be a bit more flexible with using Everbridge for internal communications. We started using it for internal incident notifications a few months ago, and having that group lookup, allowing me to create a relation between a property and a variable in the template, and who should be contacted as far as a group in the organization goes, is going to allow for some nice self-service for our internal folks when we transition to a different Everbridge organization for our internal coms.

With their templates, you can only have a maximum of three phases: new, updated, and resolved. It's not always that easy when we open up a call, that we identify who we need, page out, and we're good. A lot of time it requires multiple page-outs. Being restricted to those three phases, there's no way to say, "I want this variable to be persistent, and this one to not be." Everything that you select will be brought over as you continue. In our environment, as we have many different call-outs that have to happen, even though they are incredibly simple to select and execute now in Everbridge, it is quite the long list. I would like to make it a bit easier and more intuitive. I would like to see a bit more flexibility and tighter control over the templates and the variables you can create.

Also, they still have a limitation due to their partner, I believe it's Twilio, where, if you're on an incident call, there is a four-hour time limit. We often have calls that go over four hours in length so people have to drop and rejoin to reset their four-hour timer. It's a minor inconvenience, but it's not ideal. That is pretty persistent with any IT alerting partner you go with.

We've been using it for a year. There have been a couple of instances of our encountering some weird issues with the calls being dropped, or people not being able to hear. That was more towards the beginning part of our go-live. We ended up identifying it through troubleshooting with Everbridge and Twilio and different networks. It was an issue with an AT&T circuit somewhere. They were kind enough to give us a different set of bridge numbers so that we were going on a different path. Since going to those numbers, we haven't encountered that same sort of instability or call-quality issues. 

Other than that, occasionally a service advisory will go out from Everbridge where a certain communication path is having issues. But those are typically quickly resolved. We are pretty comfortable with the stability.

We've had no problems with scalability. We brought in Everbridge shortly after we had bought another company and started merging together into a new, unified company. That, obviously, brings some substantial scaling challenges. But we've encountered no issues with adding many, many more users to the system over the last several months.

We only have a couple of hundred people directly interfacing with Everbridge, maybe a few hundred. But as far as the users we're communicating to, it's a few thousand and that keeps increasing as we progress.

Everybody I've dealt with at Everbridge tech support, barring one individual on their staff, has been pretty nice to work with. They're knowledgeable, they're helpful, they want to assist. There have been a couple of times that it's been challenging to get the escalation that we were looking for. We were hoping to get some more urgency, especially when we were first going live, with the instability issues we were seeing. It took a little longer to get that escalation that we were looking for, but once it happened, we certainly got the amount of attention that we needed on the issue. For the most part, after that experience, it's been pretty good.

We were not using a different solution previously for IT alerting. The on-call schedules were managed and stored in ServiceNow. As I said, the reason behind getting IT Alerting was that everything was manual. We weren't using a competitor like PagerDuty or xMatters.

The initial setup really depends on the environment you are operating in. They can easily integrate and do imports from an HR system and from ServiceNow and from many different applications. They do have a lot of good options that you can easily get things set up with. For internal reasons we couldn't do it, but I definitely saw that the ability was there to do it. I would call it straightforward.

We did the deployment in under a month. It was a pretty aggressive time frame.

We didn't really have an implementation strategy. We were focused on getting the users that we wanted to bring over from ServiceNow identified and on marrying up that data with what was going to be in Everbridge. You can pass that information along through the API connector. We ended up just doing an export and then manually uploading it to Everbridge.

It was a matter of identifying who was in the system that we needed to get in there as a contact. From there, our strategy was to get meetings scheduled with the high-level folks who pass information down through the disparate on-call groups that they're in charge of, so they could let them know what changes were coming.

One big part of the overall strategy was having executive backing, because going from one organizational culture, where folks are used to having a certain amount of time to respond to a bridge call, to Everbridge, where we wanted to have the system escalate, and escalate quickly - since when we engage those folks on a bridge call, it's because we're losing money and our customers are losing money - you have a lot less time to respond to a call before it escalates. Obviously, people who are living on-call schedules are not going to like that kind of news. If you don't have that executive backing, then people aren't going to be as quick to adhere to the new organizational culture of, "you need to be on a call within a few minutes, if we start paging you." There would be no more of this, "I'll be there, when I can, in 15 minutes."

We had our integration consultant from Everbridge on hand. There were no third-parties.

We have definitely seen ROI, not in terms of dollars and cents, but the mean time to restore from major incidents has been more than halved in terms of duration. Being the company we are, in the financial world, and with how many transactions are processed through us in a second, the potential financial savings from even just a minute of reduced outage time can be substantial.

For the one-way license, which refers to someone is just on the receiving end, it's very affordable. I was actually surprised that it was a really good price. The two-way license, like for an on-call resource who is actually going to be in a calendar and be paged, it is a bit more expensive, but for the gains that we've realized, it's certainly worth the price.

We looked at MIR3 - they are called OnSolve now - and we looked at xMatters. MIR3 just didn't check enough boxes. It didn't seem like a good solution for storing and managing and quickly engaging people on bridge calls. xMatters and Everbridge seemed to have a better, more intuitive user interface, more robust options, better reporting options, and more flexibility.

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.

The primary use case of how we started using the product was to add contacts to Everbridge as if it was an Active Directory. We have logins for manager and member portals. The manager portal gives total access and member portal is given to everyone with partial access.

We also use it to send out communications, such as emails, during major incidents from our command center. We have expanded its use as an emergency notification tool.

The rotation and replacement options save our managers a lot of time.

When scheduling, it gives us the option to amend times or replace someone (with an explanation). 

The rules option has been helpful, as we can adjust the conditions in the template.

Explanations are limited to 500 characters in description fields.

While the reporting is good, we are having a problem with one particular report which is creating a large manual process for us.

We don't have stability issues.

We have been able to expand the tool and are planning to take it to the store level.

In our organization, we have 390 management users currently. We are looking to add 250 more. We have requested to have 650 management user licenses in the future.

We currently have 9000 member users. We are looking to add another 3500 member users, so we have requested 12,400 member licenses.

We would like the tech support to have better response times. Since we are looking at going global, they have told us Everbridge has told us that they are working on the issue.

Overall, their responses have been good.

I personally would rate the technical support as a 10 out of 10.

Previously, we were using xMatters, then we moved on to Everbridge because we thought there were some limitations xMatters when we used their templates and there were a lot of delays with sending out notifications. We also did not feel that xMatters product was user-friendly.

Initially, we thought it wasn't complicated. However, we did have some issues with stability and had to reach out to the support team. Later on, it wasn't difficult.

The deployment took about three to four months.

We have four team members on our Everbridge team.

It saves us a lot of time.

It is the best tool that I have ever used.

Incident reporting, mass notification to all offices and employees.

This product has allowed the teams to focus on troubleshooting rather than dealing with the administrative task of having to notify individuals or groups about incidents. This has saved man-hours and has already paid for the product.

• Mass Notification and Conditions - This streamlines the process of notifying the proper people of an event without team members having to look up who they need to notify. 
• Calendar - Having the Calendar built in allows for on-call rotation to be set once and left alone.
• Slack Integration - Being able to have all the information from an incident and discussions documented through Slack, without input, is a great asset.
• Email Ingestion - Having the ability for ticket generation to auto-generate an incident through Everbridge has saved my team hundreds of man-hours it would have taken to manually create them. This aspect has been one of the driving factors in continuing to utilize Everbridge and finding all the new ways the tool will help with day-to-day operations.

An ability to get to the database that houses our information would be great. Currently, we are at the mercy of Everbridge and, if they do not have the function built, we cannot gather the information that we would like.

I have never experienced a stability issue. We once had an issue with the built-in conference bridges. After troubleshooting, we were able to determine the issue was on our internal PBX system and not Everbridge.

So far, no issues with scalability. Anytime we have a request for a function, they work at meeting that request and eventually get it to us.

Technical support is great when working with our direct account representative. Sometimes, when using the email support, there is a communication breakdown and it can take a while to get issues resolved.

Our previous solution was to get on the phone and on email and try to remember who needs to be notified. We switched to this product to assure standardization of notifications and to create groups of people who need notifications.

The initial setup was straightforward. My team and I did a lot of research and prepared what we knew we wanted, upfront. This enabled the onboarding process to go quickly and smoothly.

The number of man-hours saved, and the standardization of notifications in mass form, have paid for product time and again.

We did not evaluate other products, as this product met all our criteria. We have had companies come to us since the implementation of this product, companies which offer the same types of services. None of them has been able to show us theirs is more robust or worth moving to.

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.