The initial setup was very complex. We did not have a very good experience with our initial deployment. Most of this was due to customizations in our ServiceNow instance. When we were using Everbridge as a standalone tool, that implementation was relatively straightforward to get some immediate value. When we went to integrate with our ServiceNow instance, we ran into a lot of challenges. 

We didn't have to, but we made the decision to re-integrate at the end of this past year. That reintegration was very easy and seamless. There was a lot of upgraded functions put into the connector by Everbridge, which have been installed in ServiceNow.

The first time around, it took us a couple of months, a lot of headaches, and a lot of effort. Our second implementation was a matter of hours before we were up and running again. It was a massive improvement from our initial implementation. Half of the improvement was the connectivity capabilities and upgraded connector that Everbridge designed and had certified in the ServiceNow Store. The other half of it was the realization that a lot of our challenges the first time around were based on customizations that we had in our environment. What we did ahead of this implementation was return to the out-of-the-box configuration in our ServiceNow instance. This allowed all of that automated connectivity to just take over, so we didn't have to customize or script. It really was just plug and play. Remove the old connector and install the new one, then do a bit of configuration settings and we were good to go.

I wasn't actually doing the install, I was leading the program and working very closely with the folks who were administrators of the tool. The feedback I got was that it was actually very intuitive until you'd get a little bit into the weeds. Some of the complications of the environment resulted in a few challenging topics. They weren't showstoppers. We never felt like we couldn't keep the ball rolling

It was a little bit of both. The initial response felt very reasonable, very intuitive to the extent it's possible, but it's a sophisticated enough system that there were parts of it where you scratch your head and you say, "Well, where do I go for this? How do I log in and change the administrative configuration of group names?" That sort of thing.

That's where some of our initial Professional Services help came in. We did pay for the implementation Professional Services. That was worthwhile, it was appropriate to do that, and they helped a lot. Wherever we did find some of those points of confusion, those were good learning experiences for us. They were good usability conversations with them.

They continue to develop, and they're very good at taking feedback from their customers and figuring out how, or if, to include that feedback in future releases. And their release cycles have gotten faster. When we first signed up with them, they were probably doing two a year, and now I think they're closer to four a year. And some of what we fed into them is already making its appearance in their code base.

I wasn't here when they set it up. I would guess that it was probably complicated.

I was involved in the setup at my previous company and I felt that it was a straightforward process. The hardest part is actually getting the calendars out into Everbridge. If your support team has a standard rotation, no matter how complex that standard rotation is, it's very easy to build that out in Everbridge.

It's when you have groups that don't have any type of standard rotation. Getting them to move to that when they're used to working off a spreadsheet and they prefer working off a spreadsheet, can be a difficult transition because now they're going to a tool.

The API integration was a little tricky in ServiceNow, but I don't know if that was due to Everbridge or my ServiceNow. We did get it worked out and again when I say it was tricky, it took us an extra a couple of weeks because we found some nuances that we weren't expecting. It took us a while to track that down and get that switched.

Now, going to Smart Orchestration, which is what we are implementing right now, so far has gone much smoother than what the API integration was. Mainly I think because I and my partner have access to actually see what the Smart Orchestration is doing versus with ServiceNow, the admins did that. It was out of our control and we didn't know what was going on behind the scenes.

With respect to how long it took us to deploy, I want to say it probably took about three months. We thought it was going to take us about a month to two months through the API, but it took us three because we ran into a little snag.

In comparison, for this Smart Orchestration, we actually have fewer resources working on it and we've only been working at it for about a month and I'm told that we're just about done. It has taken a third of the time and fewer resources.

In terms of the deployment strategy, we had very similar work streams that we wanted to accomplish through this. We wanted to send engagements under certain conditions, and implement call-outs under certain conditions. In fact, under Smart Orchestration, we have even more work streams going than what we did through the API. I wouldn't say that it was more complex this time around, but it's larger. There are more ways of triggering events through Smart Orchestration than what we set up with the API.

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.

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.

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."

The initial setup was pretty straightforward. Everyone on the implementation team had a good understanding of it and, once Everbridge turns it on, they let you play with it, so that's good. And then they sent out a team to do training. We had a pretty good handle on it, so the training was more addressing our questions. They turned it on about a week before the training crew got out here, to let us start messing around in it. We were able to figure it out, so by the time the training crew got here, it was more like questions and answers, except for our PR staff who hadn't played with it at all. They got a full top-down, step one, step two, training, whereas the Admin folks got a bit more Q&A. They were really adaptable to what were trying to do.

It was pretty straightforward.

The initial setup was pretty straightforward.

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.

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.

Since I have already done the setup with our competitor, I pretty much understood the project.

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.

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's a SaaS deployment. I'd rate it a seven out of ten in terms of the ease of setup.

We have a central Everbridge contract, and we just set up a new customer within Everbridge. It probably only takes us two weeks.

The initial setup was very straightforward. The configurations took us a day and a half to be completely set up. We saved the last half a day in case we ran into problems. After, a year or two of using it, never found a problem. Therefore, it was very easy to set up.

The initial setup was very fast with the controller coming online almost right away. The implementation team assisted us in onboarding our users and calendars. The complex part has been in transitioning our user community to the new system.

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.

The initial setup was probably somewhere in the middle, between straightforward and complex. I think the some of the harder parts were the importing of all the data.

Straightforward. It is software as a service. We had a brief setup and training session.