We did not have something that was similar to xMatters. What we had was an old-fashioned analog method of on-call management, in which people would share a cell phone. The cell phone would be handed from person to person as they went off-call. We had staff who sat in our operations center, 24/7/365. They had the list of phone numbers in a document on their machines that gave them the cell phone numbers to call for each group. So there was a system, but it wasn't a modern solution.

Prior to this, I think that we just used SharePoint and Excel spreadsheets to handle on-call data. We have been using AlarmPoint probably since 2005, which is old-world xMatters. It was the old version of the product, and then in 2018, we moved to xMatters, which is a cloud-based solution.

The primary reason for going with xMatters was that we wanted to be able to automate the call-out process specifically for some of our high-priority systems at the mainframe. It is an expensive process to have an L1 person sit there 24/7, even during the quiet hours, just in case one out of 50 times there is an alert from midnight to 5:00 AM UK time. This allowed us firstly to not have to cover those periods because we could just set up an automated process where, if there was an issue, it just calls out the user anywhere. At the time, it was one of the only products available that allowed us to do that with as much configuration as we needed.

I have not used any similar solution. This would be the first one for me. I know ServiceNow offers one, but I don't know how good that is. I have heard of a couple of other solutions such as PagerDuty, but I don't know anything about them.

We previously used OnPage. We switched because OnPage didn't have the ability to create groups and on-call rotations within a group. That was a big reason. That was years ago and maybe a newer version has that, but back then it did not.

This is the first solution of this type that we have used.

We didn't have a solution prior to this one that had this level of capability. We had communication tools (notification tools), which were very rudimentary black and white. They were very inexpensive as well, but it was just simply a list of the email addresses, potentially mobile numbers, and a notification. Then, it could send a text and email, letting people know that something was there. Separately, there was a spreadsheet that listed all the different technology teammates and the teams themselves. Then, the individual technology teams would determine what they used to manage their on-call schedule. Some people used Excel spreadsheets, some people used Outlook calendars, and some people used anything in between that they found valuable to them. There was no standard or consistency for the operational teams on the call calendars.

When we brought in xMatters, it sort of standardized it, to say, "Hey, this is what we are using moving forward. You are required to stop using your Excel spreadsheet or Outlook calendar, instead baking your information in here." 

This was initially met with some skepticism five years ago where people would say, "We have a real unique case." However, xMatters' features having different shifts so you can: 

• Create multiple or overlapping shifts. 
• Create rotations based on a recurring date and time based on the number of events. 
• Cycle first to last or last of first. 

There are a lot of options and features that surprised our larger organization. For example, with the spreadsheet, we had to go in and update it ourselves, even though it was pretty simple. Now, we literally can just go in, set this up, and configure it. We have some pretty complex teams who have third-parties that do some support for us overnight, only Monday through Friday, but even the most challenging on-call schedules were able to be configured. I think that won them over at the time, since we never had anything that managed that prior to xMatters.

We were looking for a solution like this because it was a lot of manual work, on all fronts, for teams to manage. There was no standard for the operational teams to view or find out. Oftentimes, we would get old, stale information or the spreadsheet wasn't updated in the right place. As we continue to grow, this just becomes more challenging. We also wanted to standardize our messaging and have the ability to template things for consistency’s sake, just to kind of pull it all together. So, we could say. "When this event happens, these stakeholders should know." Previously, that was always manual. We would have SOPs and processes that we would review, then we would have to craft that message up. For example, we may have an old Outlook draft that we would kind of pull up, etc.

Previously, we had BMC Remedy, but now we are on Jira. So, we were able to integrate with Remedy, and say, "When these conditions are met, automatically notify the on-call team and let them know that they have a high ticket in their queue. It requires a response." That provided a level of tracking for the operational side to be able to say, "Okay, Erik responded on his mobile phone with 'Accept.'" That would, in turn, update the ticket, to say, "Erik is now assigned this ticket because he accepted it." Once we moved over to JIRA, we lost a little bit of the functionality, because it's not as intuitive as Remedy, but we have still been able to make it work. 

The automation of our incident notification process was really useful when we had Remedy. Remedy was awful at emailing people. You would have a ticket assigned to you in Remedy, and it was supposed to send you an email to let you know. However, more times than not, the email server for Remedy would end up getting tied up and fail. Then, those notifications didn't go out or were going out really late. All of that would impact the performance of the tool itself. So, we made a conscious decision to turn off or disable all email notifications coming out of Remedy. We moved them over to xMatters. So, we can know when a ticket is assigned to a group, individual, or if it has a certain keyword. field, or property equal to something. All of that can be done out of xMatters. That has really increased the level of adoption for some of our technology teammates. There are about 800 subscriptions out there now. 

When we moved to Jira, it was able to email, but some similar things have happened where the emailing of stuff can be delayed. Most of the time, the majority of people in technology now don't really complain about that because they already have their subscriptions in place. We just had to update them to point towards Jira instead of Remedy when we decommission the Remedy servers.

Our team inherited this product. Therefore, we were not involved in the decision-making or evaluation of the product.

We used Excel, and we literally used to type the name of the week, month, and the name. So, it wasn't like a solution. It was just uploading data. It wasn't that good.

I have not used a similar solution previously.

I have not used another similar solution.

I have experience with Atlassian. The intuitiveness becomes a trade-off. I think that if a system offers a simple level of managing who's on call and things like that, then it is more intuitive to use, but you are constrained by that simplicity, and this is what I was saying about xMatters. It's a really powerful platform. You can do a lot with it, but that means that they have this challenge of how do they make it more intuitive to achieve certain aspects.

We used another solution, but that was more than 15 years ago. I believe it was called Automation Point, but it doesn't exist anymore and it didn't have an integration into Micro Focus Operations Bridge Manager or the predecessor product.

Before xMatters we had a small portal where people could update their mobile numbers, whereas the ITSM product contained the on-call list. Managers would go there to update that list. But it was not being maintained properly and we had a tough time reaching the actual on-call person. With our first priority being to return our service back to available when there is a disruption, we got to know xMatters and replaced the old system.

PagerDuty is probably the only other solution that I have used. xMatters tops PagerDuty in terms of ease of use for sending out communication to the business. I like the workflows and the layout of xMatters. It is very easy to use. PagerDuty isn't so user-friendly. The only thing that is better in PagerDuty than xMatters is the scheduling.

We originally used a tool called AlarmPoint. We used it for about the first year and a half I was here. We were planning on punting it because it wasn't very useful, and when we contacted the team to tell them that we were going to not use their tool anymore, they said, "We're no longer AlarmPoint, we're xMatters, and the tool that you're using is years old. Why don't you see what our new tool can do?" That's actually how we were introduced to xMatters. So, we previously used an old iteration that was very outdated.

We also did use PagerDuty a little bit, which is a competitor of xMatters. And the reason we chose to go with xMatters over PagerDuty was that, while both were very good at alert notification and escalation, when we did our assessment, PagerDuty did not have the ability for the major incident notification process that we needed to implement as well. It's more just for alerting on-call people when there is an issue with the server, and not necessarily for assembling a large group of people, whether they be business, technical, management, on a bridge to actually provide information and collaborate.

We didn't have a single solution. People were passing around spreadsheets, and we had a Lotus Notes database that some people could access to refer to the information, but not everyone. So, it was essentially just a mess. From that point of view, xMatters has just given a huge boost. xMatters is far superior in the way that it is highly configurable, and its features really support the actual use cases of an engineer. If an engineer is absent, they mark themselves as away, and if you have set the rotas correctly, xMatters will automatically schedule in a replacement resource. That's a very simple thing, but without xMatters, that was a very laborious and manual task for engineers. If they forget to do it, then suddenly, you don't find anyone on call. The way xMatters automates this is just far superior to the previous solution that we had.

We didn't use any other solution previously.

We basically used an advanced SharePoint site that allowed us to do a search to figure out which team supports a specific application. It gave us instructions on how we would engage that team. It wasn't a communication vehicle. It was more of a contact or a phone book for looking up a team, but it wasn't a communication vehicle. We had to use the phone and our email systems to contact those teams that support a specific application. It was more of a phone book lookup system.

I have personally not used any other solution. I've been a recipient of notifications from other solutions, but I haven't built or sent notifications through other communication vehicles other than Outlook.

We did not use a different solution previously.

We had no prior solution.

We used a legacy, half in-house written, half vendor supported on-premise solution. Our customer desired a cloud-hosted solution to take advantage of new technologies, integrations, and provide for DR stability during IT outages impacting on-premise infrastructure components.

No, we did not have a previous solution. We have always had xMatters and have been satisfied with the product.

We did not have a solution prior to xMatters.

We used manual methods previously, so this was a great improvement.