Senior Crisis Consultant at a manufacturing company with 51-200 employees
Consultant
Feb 2, 2023
I manage the product a little bit. I don't have a great deal to deal with it hands-on. Our company uses it on behalf of other organizations. We have an emergency call center, and companies will call in, and our call center will activate notifications on their behalf via Everbridge.
Crisis Management Director at a healthcare company with 10,001+ employees
Real User
Apr 25, 2022
Currently, we use it for two different things. One is from an intel perspective where, within VCC, we have the assets plotted. So, if something does occur, we can see where our assets are in relation to where a risk event occurs. The other one is for business continuity. If there is a potential crisis, we send a notification using Everbridge, but we use it through another program called Fusion. So, we send an Everbridge notification activating the crisis response team. We are currently using a customized version that doesn't have all the capabilities that Everbridge normally has, and we are now transitioning to software as a service. Currently, it isn't a cloud deployment, and that's the reason why we don't have some of the data supporting it. It doesn't have data sources and a whole bunch of other stuff that I know that we should be using. We use VCC, and then we use the regular platform to send notifications, but the data isn't as customizable. Things such as data sources and stuff behind it aren't there. It still has HR data incorporated into it but not the actual data sources. I can't see why these alerts are coming, other than little snippets that show that it comes from the news or whatever the general source is. I can't actually link to it or adjust the data sources. That's why I'm encouraging them to go to the updated version because of the additional capabilities.
Senior Systems Administrator for Enterprise Monitoring at a pharma/biotech company with 5,001-10,000 employees
Real User
Apr 15, 2021
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.
Principal Architect at a energy/utilities company with 10,001+ employees
Real User
Jan 22, 2021
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.
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.
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.
Communication Manager at a tech services company with 1,001-5,000 employees
Consultant
Dec 2, 2018
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.
Senior Analyst at a retailer with 10,001+ employees
Real User
Oct 28, 2018
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.
Office of the CIO, Service Excellence at a agriculture with 10,001+ employees
Real User
Jun 11, 2018
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.
Everbridge IT Alerting is a closed-loop cyber security and incident response automation solution that helps organizations respond to IT Incidents faster and improve teams’ response performance by automating communication, collaboration, and orchestration processes for ServiceOps, IT Security Ops, DevOps, and Disaster Recovery Ops. As a FedRamp-certified solution, IT Alerting capabilities include in-depth scheduling/calendars, interactive & analytical reporting, on-call scheduling,...
I manage the product a little bit. I don't have a great deal to deal with it hands-on. Our company uses it on behalf of other organizations. We have an emergency call center, and companies will call in, and our call center will activate notifications on their behalf via Everbridge.
We are using it for IT alerting. It is for contacting on-call personnel. We are most probably using its most recent version.
Currently, we use it for two different things. One is from an intel perspective where, within VCC, we have the assets plotted. So, if something does occur, we can see where our assets are in relation to where a risk event occurs. The other one is for business continuity. If there is a potential crisis, we send a notification using Everbridge, but we use it through another program called Fusion. So, we send an Everbridge notification activating the crisis response team. We are currently using a customized version that doesn't have all the capabilities that Everbridge normally has, and we are now transitioning to software as a service. Currently, it isn't a cloud deployment, and that's the reason why we don't have some of the data supporting it. It doesn't have data sources and a whole bunch of other stuff that I know that we should be using. We use VCC, and then we use the regular platform to send notifications, but the data isn't as customizable. Things such as data sources and stuff behind it aren't there. It still has HR data incorporated into it but not the actual data sources. I can't see why these alerts are coming, other than little snippets that show that it comes from the news or whatever the general source is. I can't actually link to it or adjust the data sources. That's why I'm encouraging them to go to the updated version because of the additional capabilities.
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.
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.
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 use it to consolidate and remove a lot of manual processes from the enterprise notification space.
We use it for technical engagement and stakeholder communication during major IT outages.
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.
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.
Incident reporting, mass notification to all offices and employees.
We use it for the email integration portion.
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.