How do you or your organization use this solution?
Please share with us so that your peers can learn from your experiences.
We use Everbridge for IT on-call management of both P1 issues (through our integration into our ServiceNow platform) and on-demand P2 bridges. These are generated by our critical incident management team, which leverages our Skype (and soon Teams) environments. When an incident occurs, the appropriate on-call calendars are hit and the critical incident team coordinates the issue as it is worked to a solution. Each of the groups has one or two group managers who keep the calendar up to date and assist on-call personnel who have questions about how to interact with the platform.
Our primary goal is to find an enterprise-wide notification solution so I'm looking at multiple solutions to find a product that could solve, say, 80% of our notification needs. We've just rolled out Everbridge. My involvement is more at the strategy level, determining whether the contract is good enough from a financial standpoint and those kinds of things. I'm the principal architect and we are customers of Everbridge.
We use this product for engagement to critical outages, so we use the smart bridge functionality. All of our entire support staff is in Everbridge. Anybody and everybody that we need to get ahold of from a production perspective is in Everbridge, and we use it to engage them. This can be both singularly as an individual or as a group, and it has a calendar that escalates up the chain. If a primary or secondary don't respond within a given amount of time, it'll go all the way up to, in our case, the VP, which is what's required by our organization. We also use it to send out notifications to support staff, if they have a ticket in their queue that hasn't been assigned to somebody after given an allotment of time. I think it's about 30 minutes. So, if a ticket is sitting unassigned, it'll notify that team saying, "Hey, you've got a ticket out there", and they can actually respond to that particular text message saying, "yes, I accept". At that point, Everbridge will then tell ServiceNow that this support person has accepted the ticket, and ServiceNow will then assign that ticket to that person. So, they don't even have to log into the system in order to do that. We also are using it under certain conditions for critical alerts. If we've got a set of alerts set up such that if one of these is triggered, something imminent is going to happen, then it will engage both a SWAT team and my incident command team at the same time, stating that a bridge needs to be set up immediately for this particular issue. Everbridge does all that for us. It also does incident subscriptions. For example, if you want to be alerted for a given platform, for a given priority, it'll send you a notification saying, "Hey, there's an issue in your platform". We send communications through it, which are self-serve from the business perspective, stating that, again, what type of platform or application that you want to be notified on. If there's an issue in that particular platform or app, you will get the notification, again, that something is going on and all of the details thereof. It is also selected by priority, so if you want only to know about the priority one, twos, you can select just those. Or if you want to know about the non-majors, threes and fours, you can also opt into those.
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.
The primary use case is for us to mobilize and engage our IT workforce in response to either major incidents or critical monitoring alerts that require immediate response. We run anywhere between 150 to 180 major incidents per month. We also use this for our critical ticket management, as well, which is roughly 200 more a month.
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 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.
We use it to consolidate and remove a lot of manual processes from the enterprise notification space.
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.
We use it for technical engagement and stakeholder communication during major IT outages.
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.
We use it for the email integration portion.
Incident reporting, mass notification to all offices and employees.
The primary use is to engage, to notify, and engage IT team members when an outage is underway. We do use it for proactive notifications, but our primary use is to communicate with support-group team members when we need to get their attention and fix a problem. Some of the features we were looking to achieve included proactive notifications, for a situation where we might have a database server that has 50 databases on it. That means if I shut down that database server for patching, all 50 of those databases are offline and multiple applications, anywhere from 50 or more, are also going to be taken offline. We use this Everbridge IT Alerting tool as a "polling" product to reach out to the stakeholders of those 50 databases and give them five options of day of week and time of day, and say, "We have to shut the server down. You get to have a voice in when we do so to minimize the impact on you as a business stakeholder." We've been leveraging the product to do some of those proactive outage notifications and polling capabilities as well. We are also striving to integrate it with other parts of our IT operating ecosystem. We already use it to communicate when a monitoring alert triggers one of the reactive notifications, and we are seeking to implement more of a full loop between that event and an incident being opened in the service management system. We're not quite there yet, but we're walking in that direction.
What do you like most about Everbridge IT Alerting?
Thanks for sharing your thoughts with the community!