How do you or your organization use this solution?
Please share with us so that your peers can learn from your experiences.
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.