xMatters IT Management Reviews

We have it integrated into our incident management system. We also have it integrated into a homegrown alerting and monitoring solution, where it does some automation and self-healing behind the scenes. 

We are working on an email integration for our service desk, similar to how xMatters themselves have it set up. 

It provides incident notifications, subscription notifications, etc. 

We use it for triggered tasks or events. Whenever a high ticket is created, it automatically notifies whomever is on call for the ticket that is assigned to a particular group, which was really one of our first use cases for it.

We saw the value by being able to import everyone's schedule into one common central repository and have one tool for all the operational teams, or any team for that matter. It gave us the technology to find out who is on call. The incident management of xMatters' integration was another key aspect, where we could say, "You can configure this when a high ticket fires." 

We had people who would say, "Oh, I didn't get that phone call," or, "I didn't hear that message." The level of logging within xMatters is pretty extensive, which has allowed us to confirm or deny if someone is saying, "Hey, I didn't get that message." It says right here in the log that you not only got it, but you answered it and hung up halfway through the message. That was a little bit of a game changer for us because it gave us the ability to validate whether or not these messages were going out. This wasn't much of a problem previously, but it has been just another tool in our tool belt to be able to confirm that this stuff has been working as expected. It puts the onus on the engineering and development teams to respond when they have been being paged or notified.

I use xMatters logs on the operational side. The logs are not really something that the other teams use as much. We use it to just make sure the notifications are going out and being delivered successfully to individuals or teams when we are sending them out. I get a rare call or request from someone on the apps teams, to say, "Can you show me a little bit of the reporting to show me how many times that my team was notified or paged from xMatters since January?" Then, I will go in and show them how they can run those reports, but also get that data for them. They may be trying to justify additional headcount next year, or something along those lines, e.g., some teams get contacted more often than others and these teams seem to always get contacted more." They are looking for anything, which they can take advantage of, to show the volume of work or amount of times that they are getting called.

I have some folks in our reliability engineering team who have taken advantage of xMatters and integrated it with a couple of our monitoring systems, then wrote some custom code to do some notifications. It not only can receive incident data from Jira, but it can also reverse that workflow and create incidents based off of different alerts triggered from external services. So, they will see an alert fire, create a Jira incident, notify the team that is responsible for resolving that issue, and then record that acceptance or decline from that notification into the ticket. It then essentially correlates those events. In a couple of cases, we have even had some help via self-healing or automation that would kick off and run like a script to recycle a server, cloud instance, or something automatically based on that alert. After that is done, it will do a validation check. If the service is responding as expected, then it will automatically close out the ticket.

We have some standards in place for technology. These go back over 10 years, even before xMatters. Having a tool that keeps it all in context has helped. It does automatic escalation, so we bake that into whatever the on-call team is. It will contact the primary, waiting 10 minutes and contacting the secondary, then waiting another five minutes and contacting the manager, and finally waiting five more minutes and contacting the director. That has been the standard for over a decade. In the past, it required a human to do that, so maybe 10 minutes was actually 12 minutes after the first wait time. Since being automated, there has been a level of consistency. It knows, "My wait time's up. I will go onto the next person." 

It has the ability to decline. Thus, if anybody in the escalation path is unavailable, then they can hit the "Decline" option. It then circumvents that wait period. It knows, "Okay, I'm just going to go ahead and call this next person right away." That is not something that we had with the manual condition. We would need to talk to the person, wait and get their voicemail, and then wonder if they were available or not. In some instances, it has expedited the escalation. The solution hasn't really moved the needle too much on the technology here. It just streamlines it a little bit and makes a slight improvement on an existing process.

We have incorporated xMatters into our application delivery workflows for notification purposes. When deployments are made or going to be made, whether they are in a scheduled status, in progress, or completed, we leverage notifications to notify people that something has been done, is being done, or will be done. From a notification perspective, it posts messages to various teams and channels based on the condition or status of that deployment. We don't have it integrated in the pipeline itself.

There are a lot of tools that can do standard notifications. However, the one feature that separates xMatters from others is the ability for it to integrate with any system that has REST API or SOAP API capabilities.

The intuitiveness and flexibility of xMatters is very good, when it comes to customizing on-call schedules, rotations, and escalations. It allows our entire technology organization to be configured and have accounts in xMatters. We don't really use it too much outside of technology, but the ability to manage that schedule, kind of setting it and forgetting it. 

It allows us to have rotations. Folks can decide if some teams rotate Monday morning, some Friday afternoon, have different shifts, etc. The temporary absence feature is pretty widely used, so they don't have to go in and rearrange the permanent schedule, but make those changes ad hoc, saying, "Hey, I'm going away three months from now. Just plan it." No matter where they are in the rotation, it will substitute a member of their choosing. That has been very helpful.

The mobile app is now almost ahead of the game. There are some features that the mobile has that the desktop version doesn't have, such as getting a notification reminder when you will be on-call. You can set that timeframe to let you know, "Hey, you start on-call tomorrow or next week," or whatever the predetermined time frame is. You really can't do that with any desktop feature. You have to do that from the mobile app.

We use the ability to send notifications from our service desk, e.g., a lot of our operational teams notify stakeholders of outages and other things like that. Its templates eliminate or minimize any type of typos, grammatical mistakes, etc. This has brought a level of consistency to our organization as we communicate to larger management teams, stakeholders, and teammates.

Right now, the breadth of features provided by xMatters are good. I work with John a lot. We just had a call with him on Monday to talk about the next release that is coming out. We are going to set up some time next week to look at some of the feature sets that will be included in that release. Every few months, it seems like we are getting a new release. That adds something. It shows the level of commitment that the developers have to making additional improvements.

The mobile app has come a long way since we brought xMatters on board. Previously, it had lacked some features and functionality. 

Subscriptions are pretty intuitive, allowing qualifiers to say, "If it includes or contains this value, letter, or phrase, then it is helpful." Something that has been a challenge for us is the ability to add the exclude option, as part of one of those qualifiers. For example, if I said that I want to know anytime the incident priority is P1. Therefore, send me an email notification so I can be aware anytime that is the case. That is easy to do. Unfortunately, our networking team creates a P1 every time one of our store's network is down, even though it is on cell backup, which is a secondary circuit. So, the store isn't actually down. It is just that the primary is down. However, by our incident definitions, it is still a P one. This happens more often than not. 

What I would like it to do is tell me anytime there is a P1 incident, except when the ticket is assigned to this team or when this word is in the summary, but there is no exclusion option. I have been complaining about this for a couple years. At one point, we created a ticket for this with the developers to review. I assume that once enough people complain about it, they will bump it up in priority to work on. However, if not enough people think it is an issue, then they prioritize their work and work on other features and functionality. However, this is something that has been challenging for us because we have needed to find ways to work around it or just deal with it. So, I would love to see an exclusion option.

I would like them to extend the level of logging for the timeframe. There are different types of logs. Some are six months and some might be a year. We would like the option to go back so we can run year-over-year reports. I think that would be advantageous because oftentimes it doesn't extend two full years, so I can't do a comparison. Sometimes, it doesn't even extend to a year depending on what it is, so I can't go back. For example, holidays are really big for us now in terms of preparation. So, someone might ask, "Hey, can you tell me what we did last year? How many times was I notified? Do I have to staff up for this?" However, I can't go back that far with some of the data to do that. 

We have been using this solution for four and a half to five years.

It does not require any type of maintenance. There is really nothing that we need to do to care and feed it. There are always new integrations that we are working on as well as ideas of how we can use it better by taking advantage of some of its feature sets.

The technical support is very good. They are very quick to respond. I know some of their guys on a first name basis, going from our technical account manager, John, all the way down to the folks who are behind the scenes, responding to Level 1, 2, and 3 issues. They have always been very responsive when we need anything or have any questions.

I would rate their technical support at around nine (out of 10), including the online help. When you are in the application itself and click on the question mark, I love how it just provides information about the page that you are on specifically. It is always updated and the content is always relevant. I have made many comments over the years that it has some of the more useful help files and documentation compared to some of the other applications I've worked with, which is why I am rating it fairly high.

Positive

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.

I went through Launchpad, in California, for a week to get a feel for the administrative and onboarding side of things. 

We did use some folks on the professional services side to help us get it integrated with our incident management tool. Then, it was just a matter of creating some standards around it and getting buy-in from the larger organization, saying, "This is what we are going to use going forward. This is how we will do these things." 

Anytime a new teammate in technology joins the company, they need to make a request, which says, "You need to submit this request so you can get your new xMatters account and be added to the right team." It is on them to make sure they fall into the right order of on-call. So, there has been a level of training on just how to use the tool, depending on what the role has been within technology, but that has not been difficult to do. It has just been time-consuming going through the motions to get everyone up to speed.

We had a second instance of xMatters on our business continuity team at the company. They recently went in a different direction because their contract was up and the renewal costs went up significantly compared to where they used to be. So, there is a level of concern about the acquisition regarding Everbridge's potential desire to increase prices and take advantage of this very good product.

Cost is probably my biggest concern. I know the solution was recently acquired by Everbridge, and Everbridge was one of the competitors that was included in our RFP five years ago. Everbridge's costs were astronomical compared to where every other solution was, not just xMatters. 

Most of the time, Sev-1s aren't something that a tool like xMatters would be able to mitigate or resolve. We do a pretty good job with problem management, incident follow-ups, and post incident reviews. Oftentimes, we try to get ahead of those before they become a Sev-1. It might help in the lower levels, when it is still a Sev-2 or Sev-3. That way, it doesn't bubble up to become a Sev-1. However, I can't think of any specific use cases where we had a P1 incident and we were able to say, "Let's use xMatters to do X, Y, Z, and prevent that from happening going forward."

I would rate this solution overall as eight out of 10.

When we purchased the product, the main reason was that when an out-of-hours issue occurred, our command center teams were struggling to find the correct on-call resources. There was a great disparity between teams. Some teams had just their own Excel spreadsheet with who-is-on-call at the time, and some people used SharePoint. Some people were using AlarmPoint, but unfortunately, the old version was quite clunky. It was not very easy to configure the rotas. So, the primary reason why we initially got the product was to consolidate and have one centralized location where all on-call rotas would be stored so that in the event of an issue, the command center or any team that needs to contact an on-call resource would be able to easily go to xMatters, search the group, and then be able to contact the correct member of staff. 

We also use the tool as a notification product for different use cases. Initially, we only had an integration with our alert aggregator for the alerts coming from servers or applications for which we needed to engage a support member for a fix. We plugged that into xMatters, finding over 20,000 events a day. It allowed users to subscribe and say that if there is an alert from a particular server name and the event or alert summary contains X, Y, or Z, give them a call or send them a text or an email so that they are aware. Since then, it has grown a bit. The resilience team has now begun to use xMatters as their primary communication method. So, in the event of an emergency or a security breach, we use xMatters to contact all members of staff across all locations. We have more than 25 locations with over 100,000 members of staff. It's only used in emergencies. It's few and far between that they have to use the product, but they do send out quarterly text or voice calls to confirm that they have the right contact details for each member of staff. So, I get a text that says, "This is a B alert, xMatters message. Please confirm that you've received this message." They can then use that to keep track and make sure that they're able to contact everyone in the worst-case scenario or when they have a big problem.

We've now grown into multiple integrations of different products. We are now mainly looking at ServiceNow integration. We do have an in-house-built integration approach where we just use the APIs to pull data from ServiceNow and push it into xMatters, but we are looking at using the actual plugin. The banking world has pretty strict security regulations. The cloud-to-cloud integration needs to go through multiple different hoops, and at the moment, xMatters uses HTTP as opposed to HTTPS. So, currently, we are pulling the data from ServiceNow and pushing it into xMatters. We're not using the official plugin as such. It's just something that we've done via a script by using the APIs of ServiceNow and xMatters.

In terms of deployment, we're accessing our instance through the cloud-based solution that xMatters provides to us.

We have used coding to expand the flexibility or functionality of xMatters workflows. We've coded a ServiceNow script to use via the API to pull in data and transform it. We also have some parts of the IBM Netcool integration to make sure that we add relevant data or information that we utilize on the xMatters side. There is also some code to make sure that the workflows adhere to our standard or, at least, adhere to our document for the workflow.

We use xMatters’ REST API. It is pretty in-depth. It has been a nice feature to have. It has only been around for a year or two, and without it, it was a real struggle. They made major improvements, and you can now pull almost anything that you need to and create a report yourself via the API. You can also integrate with custom workflows that previously would've been a nightmare and required either getting an xMatters consultant on a call or paying them money. Now, with the API, we can insert any data we want. We can target whatever workflows we've worked on ourselves. Overall, it is a pretty good standard of API. You can also request them to add something. If you want to utilize something or pull some data from the API, they're quite receptive to including it in their development plans.

It has helped us to build workflows that meet our needs. The main integration with IBM Netcool is pretty important because, without it, we would be relying on other notification methods or just an email or an alert from ServiceNow which, in our experience, people tend to ignore. When there is an incident raised, making sure they get a text for specific issues is much better. So, we do rely on the product to a certain extent. I'm sure that there are other products out there that can provide the same solution, but it would take time for us to migrate off. With the flexibility of the workflows, we can build what we want on top of xMatters, which is something that we appreciate. It is the sort of thing that we can't live without anymore.

The workflows help in calling out people in the event of an issue, and they also allow us to notify key stakeholders of issues or security-related issues. From a resilience perspective, the tool allows us to send out mass notifications to huge groups of users at the click of a button, as opposed to previous tools that would have us spread across a day to contact X amount of people.

The time saved in terms of creating the rotas and manually doing that each week is about 20 minutes per week, but if we didn't have this sort of product available to create an alert when an issue happens in the middle of the night, it would require 24/7 eyes on the glass by our team members to pick up that alert, go to the rota, find out who's on call, and manually call them and get them out of bed, which could be an hour or two hours process. Even if they see it right away, it is still going to be quite long-winded, as opposed to this automated solution where teams can say that we know what we're going to get called out for, and we can configure that via a subscription, and then they automatically get a call out within a minute or two. There are big benefits to that. It could take hours before for more business-critical issues. We're now making sure that people are getting on the calls as soon as possible, as opposed to relying on humans and manual processes.

It has reduced our mean time to resolution because we don't rely on humans looking at screens, picking up an alert, and then picking up a call to get someone out of bed to fix an issue. Now, it is a completely automated process that could save anywhere from 20 minutes to two hours. That's assuming that they don't miss an alert, which is not going to happen with xMatters because it's an automated integration that's guaranteed. So, it has definitely improved the speed of resolution for specific issues.

In a major-incident environment, when the command center needs to reference an on-call rota, previously, they could have spent half an hour trying to find the correct rota and figure out who to call, and in the end, they probably have to just call a manager who would then know who's on call and call them themselves, which could be time-consuming processes. Now, if you support an application of a certain priority, you're expected to be in xMatters with a rota, and the command center can then easily reference that in the event of an issue and get hold of the right person.

The ability to have the rota and then configure notifications that you can directly fire them into the group is most valuable. The India shift is from 2:00 AM to 9:00 AM, and then it is the UK shift from 9:00 AM to 5:00 PM UK time, and then there is also a defined US shift and on-call hours. It allows us to make sure that everyone is going to get notified when they need to be about an issue. We can target specific locations or users with notifications. One of the main improvements I've seen since the AlarmPoint days is that the rotas are now much easier to configure and use, as opposed to the old days. So, you can configure a rota and set recurring shifts so that you don't have to do much manual work. In an ideal world, you don't have to log in every week and configure the rota of who-is-on-call and whatnot. If I'm on-call every four weeks, you can just set that up, and it should recur for you. It saves a lot of time to do the actual tech work, as opposed to on-call rotas work.

It is integrated with IBM Netcool, which is our alert aggregator, and ServiceNow. We have a Spectrum integration in development, which is a network monitoring tool, but we're reviewing whether that's going to be feasible due to the amount of data that Spectrum wants to send in. We try to control the number of integrations we have. Ideally, we want to send everything through IBM Netcool, and then IBM Netcool passes that to xMatters. That's the behavior we are trying to encourage, but if someone comes to us with a use case, we always do consider it. Overall, in terms of the range of integration possibilities, it is pretty good. When I go and have a look at their integration site to see what they have available, I see more and more out-of-the-box applications for me to try and install and test. They've got all the big ones covered. Back in the old days, it wasn't like that. So, I'm pretty impressed with it.

It has allowed us to send out communication. With the integration that we've got with ServiceNow at the minute, which we've built ourselves, we pull out major incident data and then forward that to some of the senior-level execs in the company. Most of them are not going to be reading emails as much, but they probably will if they get an xMatters notification through their iPhone app or text. If it informs of a major incident, they will obviously look at that. It allows us to make sure that they are kept in the loop. The feedback on the product has been pretty good so far for the people who do use it.

They recently released an incident module that allows users, or at least teams, to track major incidents and other things, and you can send out communication via that one webpage. You can engage on-call teams and communicate to stakeholders as well, but one thing that is missing there is a group chat. If there is a group chat on the same webpage that all of the support teams could use, it would be a one-stop shop that all of the major incident managers would use as their product to manage a major incident. Without that, at the moment, they are mainly referring to teams and then adding data into xMatters as and when they can.

Some of the workflow development work that we do for the in-house piece can be quite complicated if you don't have experience using the tool. You have to have to go through the documentation, but I suppose that's an expectation. 

When users first log on and they're configuring the rotas, it does take them a bit of time to get their heads around how to configure the shifts. Some of them do need guidance. We have got a support document, and xMatters also has a support page where they can go and read through the details. Our roles and access for each user are locked down, as opposed to just letting them access the xMatters portal because it can add more confusion because the support portal explains that they can do X, Y, and Z. So, we're removing that ability, but once the users get their head around how to configure the rotas, the overall intuitiveness of the UI is pretty good. It is simple and clean, and they don't have to do that many steps. There are probably one or two group supervisors that configure the rotas, and the rest of them log on. We've already pre-populated the contact details from our directory, so usually, they'll just go and add a personal device, if they do want to get called on a personal device, or they want to set up the app, which is pretty easy using the QR codes. The product looks nice and clean. The only thing is that it takes a little bit of work to get your head around the rotas, but once you do, it's pretty darn simple.

We've been using this solution for a good while. We've had at least four years on the SaaS-based solution, but we have been using AlarmPoint and xMatters for over 10 years. So, we are pretty well-versed with the product and its use case.

Their support is excellent. They always respond quickly. If you need to call them up and get an immediate answer, you can do that. They are happy to help whenever there is an issue. They help when there is an issue operationally with a site, and they also seem to promptly assist you when you have basic questions that you are not clear about or would like their advice on. Everything is good on that front. I would rate them a nine out of ten because some of them aren't as helpful as others, but overall, they are very good. 

Positive

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.

It was like a formal project. One of the xMatters consultants came over from the US and worked on it with us in the UK for over three weeks. It was basically a major migration from the old world AlarmPoint to xMatters. We had to make sure that all on-call rotas were migrated. We had to make sure that it was there in the user devices, and we also had to configure our Active Directory to set up the groups to manage access to each role and trigger the integration agent for IBM Netcool.

I initially was the infrastructure technician who worked on setting up xMatters, and I am now mainly responsible for any escalations with xMatters in terms of operationally managing the SSO-based access user roles. If we do have an issue, which is few and far between, and if it goes to a major incident, I get involved. I'm one of the main users, and I provide L3 support for the product. So, I'm well-versed, and I understand the product well, but at first, it requires a little bit of work. If a user were to log in and configure the office hours shift, it is not the same as just having an Excel sheet that says that ABC is on call Monday to Friday, then XYZ is on call over the weekend. To get the full benefits out of this product, you need a little bit of understanding of shifts, rotas, etc. For that, you have to go and read through the documentation, but these are the things that we expect the users to do. If you're going to be supervising one of the groups, you have to go and read through some documentation to make sure you understand what you're doing and how to configure it. If you don't want to do that, then drag and drop for shifts is pretty simple. If you want to just go and drag and drop a shift each week, you can do that, and it would be extremely simple. You have the options, but it is just that here we try and encourage its users to do it the proper way.

Its on-call schedules and streamlined escalations haven't helped to reduce Sev-1 incidents in our organization. Sev-1 incidents are always going to happen, but it has probably speeded up resolution times or at least speeded up the engagement for us to make sure that we've got all the right people on the right call. It has also allowed us to notify users, or at least affected users and executives, in a more prompt and efficient manner.

Instead of the in-house-built integration approach, we are now looking at ServiceNow integration by using the actual plugin. Essentially, what we are doing at the minute is that we have a script that makes API calls to ServiceNow to get all major incidents in the last 24 hours. We pull that data from ServiceNow via our script and convert it into a format that xMatters likes. We have a workflow configured for it, and we use the xMatters API to push or post that data into xMatters. The users can subscribe and say that if there's a major incident for my application, they want to get a notification. The actual plugin that we are looking at implementing and getting security approval for seems very simple. It is basically all GUI-based. It is simple to use. There is some work involved in terms of setting up the users in group sync, but hopefully, we'll be able to move to it because there are many more features that we would be able to utilize.

I would rate this solution an eight out of ten.

We use xMatters as our automated on-call engagement system. We use ServiceNow for major incident management and processing for the university's IT services. When there is an incident of sufficient priority, impact, or urgency, we make use of the integration between ServiceNow and xMatters. xMatters contacts our staff members who are on call to make them aware that there's an issue going on. It gets them the information they need to log in and fix whatever might be happening. xMatters can do a lot of other things, but we use it primarily for our major incident response and automated on-call processes.

In 2019, we embarked on a "lights out" process. We had staff members sitting in our operations center, 24/7/365. They had to watch the screens and make sure, when something went "bump" in the night or something went down, to physically pick up the phone and call somebody. In December of 2019, were able to bring those staff members back into a nine-to-five type of job, repurpose them, and move them into other roles. We let the machines do the hard work of notifying people if something goes wrong. xMatters was a big part of that because it allowed our managers to maintain their own rosters, and cell phones didn't have to be handed from one person to another. The process just worked really well. That was of benefit for our central IT.

We also onboarded our institution's public safety/police department. Before, if they had an issue where everything went down and they couldn't do anything from their office, they would either call or walk over to the IT building and find somebody in the operations center, and then the operation center would call somebody from networks. Now, we have onboarded several select people from the police station. They have the ability to use the xMatters mobile app to hit a big red button that contacts our major incident managers directly, without them having to do much else. That means they don't have to physically come work with us or find us. We were able to replace that physical process that existed prior to 2019 with a fully automated process now.

The automation provided by xMatters has helped us respond to incidents. It puts the responsibility for responding on the groups and the people who are responsible for providing service. They're getting a notification when something happens that meets a certain threshold. That's in contrast to the subjective process we had in place previously where the person who was in the operations center decided not to call somebody for whatever reason. Now that it's automated and everybody is playing by the same rules, there have been improvements on the monitoring side of things and in how things are architected. They know that if something goes down, they're going to get a call. Having the managers and the people closer to the process, with the ability to manage their own rosters, results in a little bit more responsibility, rather than just passing it off to the person who's sitting in the operations center.

The automated notification process has made people understand that they have to fix things before they go "bump" in the night. They know there is no longer a person sitting in our operations center who might decide not to wake somebody up. The machines are going to detect that something has gone wrong and they're going to notify xMatters, and xMatters is going to notify the group. Tangentially, that results in people proactively fixing things ahead of time. In turn, with people being a little bit more proactive in handling things, issues don't get up to a priority-one level as much. But when it happens, xMatters does its job and gets out of the way really quickly. It helps us deal with incidents when they happen.

In addition, the targeted notifications have helped reduce response times to IT incidents. It doesn't require a person in the operations center to call five people five times. It handles things synchronously. I would absolutely posit that our response time is quicker than it used to be.

In terms of its flexibility, we've been using it for close to two years, and we have yet to encounter a situation where somebody hasn't been enabled to configure it to work the way we want. We can configure groups to be members of other groups, enabling us to nest sequences of rosters, and that has been super-helpful in a number of scenarios. We provided a little bit of training and a little bit of documentation for the managers who had to manage their rosters and the sequence of calls, and since then, we really haven't had to do a lot, other than some reminders. But we just tell them the URL and that they should log in. They can figure it out from there. The UI is understandable. It's fairly straightforward to understand how you add a user or add a member to the roster or add a device. It doesn't take a lot of administrative overhead and that's important for us. We don't have a lot of people to manage every little thing, so people being able to do it themselves is pretty important.

And because we use it primarily for our major incident response and automated on-call processes, the automatic logging that's built into xMatters, especially the timeline of events, is very helpful because we can figure out why a particular person got a call. We can see, for instance, that it was because an incident showed up in that person's group and it went to the first person on-call and that person hit skip or ignore. It then went to the next person, called all of their devices, but they never acknowledged anything. Then it went to the next person and that's who actually picked up. Having that level of detail built-in makes it really easy for me or the managers to prove that's what happened, and we can self-serve that information. It gives people the autonomy to know why they got a call. Just click here and you'll see exactly why the fourth person in the roster got the call instead of the first.

The integration of xMatters with ServiceNow worked pretty easily. There was a little bit of configuration and coordination with our ServiceNow, but once it was set up it just worked. It does the right thing for us. We don't want every single instance that ServiceNow handles to generate an on-call notification. We only want priority-one and priority-two to result in notifications, for certain groups, via xMatters. It does that really well. That integration part was super-easy. I have also done some work with the xMatters API to pull out information about users and groups and rosters into a Google sheet. I used a Google Apps Script to interact with xMatters and pull information out for reporting purposes. That was also really easy. We use that information to see how many people are in xMatters, who's licensed, and if people have left the university we can make sure we kill off their accounts.

xMatters has also helped us build workflows that meet our needs. In comparison to all of the organizations that use xMatters, our workflows are not complex, but it does what it does well and easily. Our simple workflows consist of an incident coming in and the right group being contacted. Within that group it goes through the sequence of people in the roster, in the right order. That was super-easy to set up. It was also very easy to set up another simple workflow where we use Zoom and Google Meet for our bridge process. If somebody isn't sure about something that is going on they can send out a "Please jump on the bridge line real quick" message. We can use either the xMatters bridge or the Zoom or Google Meet bridges that we have set up. That helps us control access and costs because we're already using Zoom and Google.

We would like to see a greater variety of integrations with ServiceNow. It works fine as it is, but an enhancement would be the ability to interact with the major incident module in ServiceNow. In ServiceNow, you can create an incident which is priority-1, 2, 3 or 4. The existing xMatters integration allows you to filter on just P1s and P2s, or on all priorities, or on just select ones. The way our major incident process works, when an incident is elevated from a P1 to a major incident, that is an extra flag in ServiceNow. It would be awesome to have xMatters get notification when something goes from a P1 to a major and then have it go through a different workflow, rather than our regular P1. 

We purchased it in the latter half of 2019, so we've been using xMatters IT Management for about two years.

The stability has been great. I can't think of a time in the last two years that it's been down when we've needed it. They've done upgrades, but I can't remember it ever being down.

The pricing was good, from our perspective, for scaling. It hits the mark. If we had to add hundreds of users we'd take a look at what kinds of bulk discount rates they may have.

As far as the technology goes, it seems to me that scaling is pretty easy to manage. You start with the ability to put groups inside of groups and have nested rosters. There are workflows that are specific to groups or to particular processes and that makes it fairly easy to configure. I would expect it to be a pretty scalable solution if we decided to roll it out in a significant way.

Currently, we have 105 people licensed, and 102 of them are in central IT. The other three are in the police department. Everybody in IT who is licensed is an active user because they are on-call in whatever rotation has been defined.

It's yet to be decided if we will increase our usage. In higher education there have been some budget cuts and position losses. It's always a moving target regarding whether we're going to expand or contract. At this point, I don't think we'll expand the use of xMatters because we've already licensed it to everybody in IT who needs to be licensed. If we had to roll it out to other departments around the university, I don't see it being an issue. But we are a heavily centralized IT operation here. We don't have a lot of distributed IT infrastructure or staff. Pretty much everything has to flow through IT.

Their support is quick. They literally react within minutes, at times, after you put a ticket in. They've been great with any support issue we have had. That was especially true early on. We haven't had one in a while, but when we had questions that weren't bugs but just our not understanding something, they were getting back to us within minutes.

Positive

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.

We did a couple of walkthrough training sessions with xMatters staff. It involved a core group from our side, people who were going to be the admins or the main people using and configuring xMatters. I then did a handful of walkthroughs with different groups in our IT department. Those were about 45 minutes to an hour in length and I showed them the interface and how to add their devices. We did a little bit of documentation, but not much, about our process as it relates to xMatters. We then rolled it out. We did all of the training within a few weeks, once we got close to that "lights out"  deadline at the end of December of 2019.

In terms of our infrastructure, we just added the module for ServiceNow, filled in some details according to the documentation, and hit save. That was it.

As for maintenance, the only thing we've had to do is add users and remove users. It's a set-it-and-forget-it solution.

There have been savings in process and overhead that we have been able to realize. We no longer need to have our staff looking at a screen overnight, on weekends, and during the day, every day of the year. We repurposed those staff members to work of higher value.

It's billed per user license.

The way we approached it was to look at who actually needed to be on-call and licensed people accordingly. The pricing is tiered so we took that into account. If we were to license 10 or 20 people, that would be a certain price. And if we were to license 50 or 100, there would be a little bit of discounting. But the per-user license was right in line with what we were expecting.

We looked at PagerDuty, Opsgenie, and VictorOps. We considered all of them and looked at some demos, but we didn't get as far as doing a full proof of concept. The main reason we ended up going with xMatters was that it seemed that a lot of the alternatives I mentioned were built on the premise of being the actual incident management tool, and not just an on-call management tool. We were very clear that we needed a tool to do on-call management, and that ServiceNow was going to be our incident management tool. We just needed something to bring people together by notifying their mobile devices or by making a phone call to alert them in the middle of the night. xMatters fit that perfectly.

I don't think I've ever had a complaint about it. xMatters just works.

We primarily use it to automate a lot of our incident management processes. We have several monitoring tools and we use xMatters as a way for teams to receive proactive notifications from those tools. We also use xMatters to send out company IT notifications around incidents that are affecting our operations.

The solution is streamlining processes for us. Before, we had to do a lot more manually. We're a heavy Slack shop and we would have to copy and paste things. It also helps to keep our ticketing tools updated, which is nice. 

Our teams are also appreciating its capabilities. We have had a lot of team reworks lately, and teams have appreciated the flexibility it gives them to make their own changes to their groups, including escalations and rotations.

xMatters has also helped to automate a lot of our incident notification process. We haven't automated it entirely because we purposely haven't wanted to do it that way. But that automation has definitely made it easier to respond to incidents. 

We send out notifications to a wide audience in IT, to let them know the issue, the status, as well as the incident start and end. We were already using a lot of what is in the xMatters incident feature, but in a custom form. It's been very beneficial, helping to bring visibility into issues, keeping us on the same page, and having data that we can all go back to. That's been great.

The automation has also helped us with our data integrity. Because we have things more automated, we do have a lot less human error and processes flow more smoothly. And we can update things a lot more quickly. That has allowed us to improve our MTTD and MTTR quite a bit. Now, we're getting to the next level and we need to look at the root. That's where we haven't fully automated the incident process, because now we're looking at the harder questions, such as what constitutes a high-severity incident. We're starting to get to those conversations and, once we get a little bit more defined there, then we can automate it.

An example where we have used coding to expand the functionality of an xMatters workflow is that the out-of-the-box Sharewell integration doesn't work for us. The custom steps we have there are a primary example of coding expanding functionality. And before there were workflows, we wrote our own scripts to do what some of the workflows easily allow us to do now. A typical example would: trigger a flow, do some work, and then send out the notifications. We did a lot of that in custom scripts and we still have some of the logic in them now. A concrete example, where we have streamlined processes, is if we have a P1 issue. We automatically select the recipients, the stakeholder groups to notify, and we set some flags on the importance of the issue. We also set which devices to notify. We do all of that in a custom step, and that's as opposed to someone having to remember to all do that and things getting missed and not being consistent.

And while we don't have as many P1s—we have mostly P3s, and fewer P2s. We have seen a reduction in P2s, but we have also seen an increase in P3s. I think that's because we have more monitoring and more systems, so people are catching and reporting more issues and they let us know. We're then making them known to make sure they get the attention needed to get them resolved.

We love the Forms. That is my favorite part of xMatters.

Next in line is the workflow builder, which is great. It has simplified a lot of the integrations for us and it has made it easy to make changes and add new functionality. Before we had to write more complicated code. The built-in integrations, such as for Slack, make things very easy. Also, it's flexible enough that if I want to integrate with something else, I can, even if xMatters doesn't have a built-in integration for it. We can write our own scripts and query APIs and create our own web-plugs and ingest. It's very flexible.

The intuitiveness of xMatters for customizing on-call schedules, rotations, and escalations makes doing so very easy. My customers are the rest of IT within our company, and they find it very easy to navigate. There's really no need to even do much training. When we onboard someone to xMatters, we send them a welcome email with some links to do and most of it is very intuitive.

Also, its logging capabilities have improved. A few years ago, there was a shorter character limit on logs, and very little retention, but now it's great. I can go back in time and I don't have any issues with the logging limits.

We also use xMatters' REST API quite extensively, and it's very easy. We use it to keep xMatters clean. We query xMatters every week. We're trying to create more workflows using the API to automate things. For example, if we find that a team is not configured properly, that can be handled automatically using the xMatters API.

The logging limits used to be an issue, especially if we were calling Slack. Whenever you query for a Slack channel—and I don't have to do that manually anymore because xMatters does that work for me as part of a workflow step—you get all of the channels, and you can imagine how long that can get.

I've asked for the ability to have tags on groups, and for dynamic lists, meaning the ability to pull data from another location and use it in xMatters dynamically. Right now, for example, if I have a form and want to populate a list, it's a manual process. I have to copy and paste the list items. I would like the ability to have a dynamic list of teams or services. Maybe they could give me the ability to update that via an API call.

I've been using xMatters IT Management for about five years.

The stability of the solution is very good. In the last four years we may have had one or two outages. They're very infrequent. We really haven't had any issues of note. It has been working well.

We haven't had any issues scaling.

We have a little over 2,700 users and they include developers, people in operations, IT leaders, some managing directors, directors, and managers. Their main use cases are to either resolve an issue or to log an FYI saying, "This issue is ongoing at the moment."

We don't have plans to increase our usage of the solution. We've grown over the last three years and we have tapped out on growth. Unless we hire a lot more people in IT, I don't think there will be a need for us to grow.

Their support is awesome. If I have a question I can always ask. 

Also the account owners and the sales engineers are very helpful. We meet monthly and we get updates on the roadmap. We also run ideas by them, they help us work with the architects on the xMatters side to give us some working examples. It's been great. A lot of it is that we don't know what we don't know. It's helpful to hear from them, "Hey, we have some customers that are solving a similar use case in this manner." They don't get into those specifics, but they can either mock something up that's similar or just explain it. Since we're pretty familiar with xMatters, we can see if that can help us or not. 

The support is probably my favorite thing about xMatters. They respond very quickly. A lot of times, even with the first communication, we have an answer to our question. That's great. We work with a lot of vendors and that is not always the case. With other vendors, usually when you submit a ticket it takes a couple of hours for somebody to acknowledge it and then, a couple of hours later, we may get a reply like, "Did you read the manual? Or restart?"

xMatters, it's not like that. They're pretty good about understanding what we're asking. We're also more mature, so when we ask for something, we know we need help. We just follow the normal support process and we're able to get a lot of help. Support has been awesome.

Positive

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.

To start using xMatters there was some training needed on the Integration Builder, training that xMatters provided us as part of the rollout. It helped us to better understand how to start thinking about and creating integrations. That helped us to be successful. 

The robust APIs helped a lot too. We went from onboarding people via batch CSV jobs to using a plugin we wrote. We have a front end and a back end and that has a form, and that's how people can get onboarded to xMatters very easily. That back end calls the xMatters API and has a lot of the logic that we want. For example, we want team names in a certain format, and we add metadata into the team description in xMatters. That's how we're able to use xMatters and keep it updated the way we want it to be.

The only maintenance involved is our due diligence to clean users out who are no longer with the company. We query the xMatters API for all the users, and then we check to make sure that they are still there, and if they're not, we delete them, also via API call. We do that for licensing purposes too, since xMatters is licensed by the user. We are very motivated to keep that clean. It's an automated job that runs daily. It takes five minutes every day. It's not something we even think about. We get a little report via email that says, "This was done" or "Nothing needed to be done."

I think we have seen ROI, but as a company it's hard to quantify because we don't have a good way to track incidents that we don't have. The most direct correlation to ROI is the decrease in MTTD and MTTR.

xMatters is pretty good about rolling out new features on a quarterly basis, that are net-new. A lot of times there are updates to existing features, or updates to APIs, but almost every quarter there are one or two, or even more, things that are brand new to the platform. The features they provide, versus the cost, are pretty good.

We evaluated Everbridge, which has since acquired xMatters, as well as PagerDuty, and one other solution that I don't recall.

We haven't evaluated any product recently, but from what I can tell, looking around online, what xMatters has that others don't have are the custom forms. That's the big differentiator at the moment because that's something that we heavily use. If the forms are not going away and other vendors don't have forms, there's no need for us to move anywhere else.

One thing xMatters does not have though, that some other solutions have, is the ability to have a phone number that can be routed to a group, something like a phone trigger.

Look at the use cases that you're trying to address. We started with stakeholder notifications four years ago, before stakeholders' licenses were even a thing. We identified that that was the main feature we wanted and we then figured out the numbers. That's what helped us estimate what we needed from xMatters. Since then, we've added the on-call rotation which the groups have been using to get notified. Try to size it properly because if you try to get all of your IT employees on it, that may end up being much more spend than you were planning.

Draw up your existing processes to identify what you have as a whole, and then identify the parts that are manual. Figure out how you want to use the product and where xMatters can provide some automation. We did that and it helped shine a light on some places where we could use more help. We noticed, "Hey, there's a chain here that's very manual. What can we do on this?" Having sketched it out and talking about why we do each step, and making the determination about whether we still wanted to continue doing it that way, allowed us to find the most value. As opposed to using xMatters and taking over all your processes, look at your existing process and at the synergies between them and what xMatters can provide, and go from there.

The biggest lesson I've learned is to take a step back and look at the whole process, and then see what we need to do. We can do a thousand things, but if we don't plan them, understand why we're doing them, then we're not going to be successful. Taking that step back has been great. A lot of tools will overlap. Stepping back and determining which tool will do what is important, and whether the current tool even makes sense. And is there something else that it should be doing? Do we even need this step? Once you answer those questions, the rest of them are a lot easier to solve.

I rate xMatters a nine out of 10. I love it.

We're relatively light on use cases. We primarily use it for notifications. We're not using the Incident Management module, but we are using the SOAP service. So, we use it for integration and for holding all of our rotas and groups, and that's our main use case. Our local teams go into xMatters to invoke those groups based upon the tickets that get created in ServiceNow. They'll be for a particular team, and that team's on-call rota is held in xMatters.

It has reduced the time to engage engineers. This reduced time leads to improved ticket resolution and ultimately, to improved service provision for our clients, which is the ultimate gain. Our systems are down for less time because the engineers are engaged much faster.

We also quite heavily use subscriptions. We use those by way of just simple notifications to third-party stakeholders, and that has proven to be a big gain because it makes customers aware of the incidents. In addition to the resolving engineers, you can add third-party stakeholders in the notifications. Customers have been very keen on taking up subscriptions because it gives notifications to their stakeholders about the status changes of an incident and what's going on. I know that has been very well received.

We have automated our incident notification process with xMatters via subscription. So, essentially, as the support groups and engineers have been engaged to go and resolve, we also have numerous subscriptions set up so that a client's stakeholders and our internal stakeholders are notified at the same time. They would be client delivery managers from our side of the fence and then the actual client contact points on the client's side. It just gives us a very quick, easy, and effective way to increase notification awareness, and it has been very well received by the clients because they were somewhat in the dark previously. They would raise a ticket, and it would go to a resolving group, and then they would just wait, whereas this way, they're more in the loop but without being swamped with the technical detail. It is just at the awareness level, but it has proven to be very popular.

We have built workflows that meet our needs via xMatters. They're important to us. They provide very good and very configurable automation. We've found them to be very configurable and portable. We can make a workflow for client A, export it, and reimport it for client B. If it needs to be customized, we make a few changes, and it is up and running for client B in next to no time. We found the workflows to be very intuitive, very powerful, and very well received by those who would benefit from this functionality. We've found it to be a real win.

We've done custom coding where required. Most of the time, our use cases are quite simple. Wherever required, we have done extra coding, but it has been minimal. We have a couple of webhook-type workflows, and we've added extra code in there to essentially filter. There are a lot of alerts coming out of a particular system, and we've added some custom code in there to only activate certain elements of the workflow against certain priorities. 

We were able to customize the workflow so that it is only for targeted incidents or particular criteria. It expanded the flexibility or functionality of xMatters. We were able to pick an out-of-the-box workflow and customize it to summarize clients only in particular trigger cases. They wanted everything captured but only certain things to be raised. So, we had to do an amount of coding in there to interrogate their initial methods, make the webhook do certain things, and make the workflow do certain things based upon the invalid data. We found that very easy to achieve. The customer was very pleased.

The automated callouts, without a doubt, are valuable. They have been a huge gain for our company. Previous to xMatters, there was no real management of the on-call resources or rotas. So, having that centralized and automated has been a huge gain. 

The support groups themselves are the most useful part.

It is incredible in terms of intuitiveness and flexibility of customization. It is an excellent product. It is very usable. We are the local administration within our organization, and with the tool itself being incredibly intuitive and the support being possibly the best I've ever encountered, it is a joy to work on. It is very intuitive and very easy to work on.

We've got some webhook-type integrations with standalone systems that we have from our various clients. These integrations were very easy to do. A lot of applications that you'd like to integrate with already exist as modules in xMatters. So, a lot of the work is done for you, or it certainly leads you through it very clearly. These integrations are very easy and very intuitive to set up.

We have used the REST API as well, and it was very good. We found it to be very powerful and very well supported in terms of the API endpoints. If we needed an endpoint that was missing or wasn't available, we were able to get that added easily. It has been very good.

The only thing that has caught us out a little bit is that on certain screens, you don't have the same admin options. There should be more consistency with the admin options because not all screens provide you with the same options. As an administrator, it feels like they should always be there. For example, on some screens, there is an Export button that provides fantastic, detail-rich exports, which obviously are very handy because then you can, as an administrator, do your administration, and extract what has been done to share with or prove to others. However, the Export button is not always present, and on the screens where it isn't, you miss it. You're like, "Oh, where's the Export button?", which can be quite problematic. There should be more consistency in the UI in terms of available options for anything that is referenced data or configurable. If you can put it in, there should be a way to run an export function to essentially pull it out. That's the only improvement that I can really think of. There is a little inconsistency, but I believe that has been simply explained to us. xMatters has been developed and redeveloped many times. So, different hands have touched it, and I guess not everyone thinks that an Export button is required, but we've certainly found it to be a very useful function.

It predates me, and I think we're into our third year.

It is near perfect. It is one of the most stable pieces of software that I've ever used in more than 20 years in IT. It is an incredibly stable platform.

With our limited experience, it seems to be perfectly scalable. You can make it do as much or as little as required. The ability to make those changes very quickly in a live environment is very good because if a new requirement comes in, we can turn it around almost as quickly as we can type. There are very few barriers to stop you from scaling as required.

In our environment, we have less than a thousand users.

Their support is exemplary. I would rate them a 10 out of 10 or even higher. In 20 years in IT, without a shadow of a doubt, it is the best support I've ever received from a vendor. They are so attentive and knowledgeable. They present themselves with such a friendly and family-based vibe or approach that they stand out from the crowd. You almost want it to go wrong so that you have an excuse to speak to their support. They are exemplary. 

I cannot speak highly enough of the quality of their interactions, whether that's raising support through the support links on the tool itself, or when we have a monthly catch-up call with Jamie Mallon. He always comes to us with tons of knowledge, tons of new news, and loads of warmth and engagement, and that's pretty standard. They do things in a very cool way. The quality of support that I get from them is very noticeable as compared to any other vendor I've worked with, bigger or smaller. The xMatters guys are definitely the best. They do things in a brilliant way, and for Everbridge, their new parent company, there is a lot to learn. They should be adopting as much of xMatters' style as they can because they really are excellent.

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.

It predates my time on the team. So, I don't know about the initial setup. 

Its maintenance is practically zero. From our side, we're primarily doing account creations as the talent pool of resolving engineers changes and shifts. We also configure any new workflow or webhook requirements that come through. We set up the groups and support users, but they configure their own rotas because we like to get them to own that side of it so that they can look after their own team going forward. We initially support them through the rota creations to make sure it is all set up in the way they need it to be operational.

This maintenance time varies depending on the demand. We've got a relatively stable take-up at this point. At its busiest, we were spending half a working week on it. At this stage, where we've got things configured and pretty stable, we are down to a very minimal amount of hands-on support that is required from our end, which is great. The system just runs. We're called into it when there's an issue or when there's a new take on of some kind, but for the majority of it, we're able to just let it run and do its thing.

Three people work on xMatters day-to-day. We're support engineers, and this is one of the things that we look after. We support it in addition to numerous other systems we all look after. We don't look after just xMatters. There is not a great deal of work for us to deal with on a day-to-day basis when it comes to xMatters.

I'm not involved with the numbers in that regard, but logically, we must have had an ROI because we've seen service gains. We've seen increased efficiency. It obviously passed in terms of time and cost savings across the board. All of our incidents are dealt with quicker now because the engineers are engaged so much quicker.

I can't really comment on the value in terms of comparison. It could be the most expensive product in the world. It could also be the cheapest, or it could be safely in the middle. 

It feels like good value in the sense that the service is excellent. The people above me who look at such things have renewed it a couple of times, and I think they would have thought whether it was good value, whether it was wildly overpriced, or whether there were better and cheaper alternatives. So, from that perspective, the pricing is fair and proper.

I would advise others to go for it. It is great. My advice would be to engage with the xMatters resources themselves because they will engage and guide a potential new customer very fairly. They won't oversell. They will get you the correct solution, and they will be very helpful in helping you to get that to work. So, my advice would be to go for it 100%.

I would rate it a 10 out of 10. Nothing is perfect, and there is always room for improvement, but it is very hard to see where. This is an excellent product.

We use AWS CloudWatch to monitor our infrastructure, and when CloudWatch detects an anomaly, it sends an alarm to xMatters, which triggers a workflow. Depending on what the alarm is, the workflow will either try to remediate it automatically, e.g if it's the server running out of disc space, or it will look at our online dashboard to see if the affected server is in a maintenance window. If it is, it doesn't do anything else, because an alarm would be expected during a maintenance window. If it's not in any maintenance window, then it generates an instant on the dashboard so that our customers can see that the system's affected, and then it generates an xMatters alert for the on-call team, and then xMatters takes care of notifying whoever is currently on call that there's a problem to be investigated.

We recently released a software as a service platform and that required us to provide 24/7 support, something the company's never done before. I'd previously been using xMatters just within IT to monitor the systems for us, but not really for alerting us. For this service, we said, okay. We have a team doing UK hours during the week, the team doing US hours during the week, the team doing Asia hours during the week, and then we have the four-weekend teams that it rotates through. So there's that complexity that it handles for us. We've got monitoring of the systems, again, with CloudWatch, but then feeding into xMatters to alert who's on call. It then notifies the Slack channel for everyone so that you can see that something happened. Plus we've also got it tied in with JIRA service desk, so that if a customer puts in a high priority ticket, one that has to be dealt with within four hours, that raises an xMatters incident so that the on-call staff knows that they've got to deal with it very quickly. We just would not have been able to do that if we didn't know about xMatters. 

xMatters helped to automate our incident notification processes. If CloudWatch tells us that something's gone wrong, the workflow sets up an incident within xMatters and we've got it set so that it notifies the people on call. It also notifies the management team just so that they're aware that something's happened. Within xMatters, there's an incident template so that you can use that to record the steps that you take to deal with the incident so that when it's all dealt with afterward, you have everything in one place to create a post-mortem report from.

This automation of incident notification processes has immensely affected our ability to respond to incidents. It means that we can be on call on a weekend, but actually not have to sit in front of a computer all the time watching for things all the time. We can just go about, relatively speaking, our normal weekend lives, and when the phone goes off with an alert, then we know we've got an incident to deal with. It sets up a Slack channel specifically for that incident so that any chatter around what's gone wrong and how to deal with it is kept in one place and not in the middle of the general conversation, and that's all done automatically.

It has absolutely helped build workflows that meet our needs. I've looked at other platforms and I don't think I've come across anything else that allows you to write code to actually execute within the workflow, and that has absolutely 100% solved problems that we really need to deal with. These workflows also helped to address issues proactively. The classic one is the workflow to deal with the server running at disk space. So, we have it set up so that if the amount of free space falls below 15%, then it triggers the alarm and the alarm triggers the workflow, and the workflow doubles the space, and that is proactive. It handles this situation before the server actually runs out of space and that's helped us a lot as well.

We use the coding to expand the flexibility. The disk expansion one is 100% JavaScript that I've written. There are no xMatters bits in there at all. It's all written by me and actually the benefit there was that xMatters themselves don't have any support for calling AWS APIs, and so I actually had to work out how to do that. AWS APIs are quite funky around signed headers and stuff like that. That took quite a bit of doing, but it's something I've now made open source so anyone else who wants to call the APIs for xMatters, it's all there for them to get on with.

The fact that we can have different teams being assigned different areas of responsibility means that if an alarm goes off, you target the specific group for that responsibility. So, it means you're getting the right person at the right time.

One of the things that really attracted me is in workflows, you can write your own custom steps in JavaScript. You are not restricted to the steps that they provide. If you can write it in JavaScript, you can pretty much do anything. It gives me flexibility in ways that other platforms don't. For example, the online dashboard system we use is not a widely used one, but they have an API. So, I'm able to write the JavaScript steps to do things like check if a system's in the maintenance window or create an instant on the dashboard or change the status of an instant. I'm not dependent on the dashboard provider or xMatters creating steps for me.

It's very flexible. The intuitiveness of it is not great. It can be a little bit challenging to achieve all of the combinations and permutations you might want. I've had to build it out a little bit. It's not simple, but it's powerful enough that I can do it.

We have integrated xMatters with CloudWatch and the dashboard. We've actually got two different dashboards depending on which platform we're monitoring. I've integrated with that, I've integrated with Slack, I've integrated it with Google Chat. It's really easy to integrate it with third-party products.

They have a very strong selection of third-party integrations that they support. Out-of-the-box, Slack's there, Teams is there, Zoom is there if you want to set up a video call for an incident. You've got third-party platforms for data management, but even if they don't have something out-of-the-box, so long as the product you're trying to integrate with has an API and you are fairly conversant in JavaScript, you can do it yourself. It's that good.

We also use REST API. It's really strong at helping to customize processes and information. The only shortcoming I would identify is that when they're rolling out new features, the REST API can take a release or two to catch up, and that's because they'll be firming up on what the functionality is of the feature before allowing you to then start accessing it via the API. Initially, it's only handled by built-in steps. The Rest API is really powerful.

As an agent, as someone who is on call, I can mark an absence time and I can optionally put somebody in my place, but once you've done that, you can't edit it. You have to delete it and create a new absence, which is annoying, but it's not a massive issue. It's a minor annoyance. That's probably about the only thing I can come up with because I absolutely love the product. It's met our needs so well.

I have been using xMatters for two to three years. 

It's very stable. They do quarterly releases of new features. We've never had an outage on xMatters at all. It's rock-solid from our perspective.

It's really scalable. I don't think they give much away about how it's running behind the scenes, but they don't seem to place any constraints on how many workflows you have, what you do in the workflows, how many agents you have since you pay for them, that sort of thing. I don't remember any limitations that they announced.

We're paying for 15 users at the moment. Most of them are support agents for the SaaS product.

The staff for xMatters is brilliant. When we first started using xMatters we were on their free plan.

The great thing about their free plan is that it only really constrains you to the number of agents you can have using it. There are no constraints on workflows or anything like that, which is unlike other products that might have a free version they normally put limits in. With xMatters, it's only the number of users, but even there, you can get full technical support from them. When I first started writing my own steps in the workflows, not only do they help you, but they encourage you. You get really positive feedback from them and that helps you to feel positive about the changes you're making.

Positive

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.

Initially, we were using it at zero cost and it was 100% meeting our needs, and I can't say fairer than that. And then when I was asked by the department that was setting up this SaaS product what I would suggest. I said use what I'm using. It will 100% meet your needs and I've got the experience of using it. We didn't even look any further because we knew we had a product that would do what we needed it to do.

I think it is excellent value for money. I can't remember what we're paying now, but the per agent cost is extremely reasonable for what the platform does. It's entirely agnostic of where you are getting your alarms from. You could even trigger an alarm by email if you want. It's that open to what triggers an event. 

I looked at Opsgenie briefly, which was acquired by Atlassian, and I didn't get on with that as well.

I evaluated it separately and before xMatters. I was looking for a solution. We are quite an Atlassian user. We used quite a few of their products, so that's why I looked at Opsgenie first, but ultimately didn't feel that it was a good fit for what we were needing, so I gave up on it and didn't think about much else. Then I came across xMatters at a conference. They told me about the free offering and all of that good stuff and I thought that there was nothing to lose in trying this one and it just went from there.

I would rate it a nine out of ten. It's not perfect, but it's really damn close to it.

My advice would be to give it a try. It literally costs nothing to try it and there are a lot of integrations that you can easily add that xMatters provides. You don't have to do coding. You don't have to know JavaScript. It's really easy to put the steps onto a workflow and join them together. If you check for results and branch off to do different things depending on what the results are, there's basically a lot you can do without having to do any coding, but if you're comfortable with JavaScript, then the sky's the limit. You can really go for it.

The primary purpose of the solution is to manage callouts to support staff for groups based on incidents created by ServiceNow. That's why we bought it, though we expanded its use since then and use it for a few other bits and pieces. We use the product's Workflows feature to integrate with Teams to get information and alerts sent to our Teams channel.

Our primary integrations are with our ServiceNow platform, MS Teams, and Slack, and for our current project, we are looking into getting xMatters integrated with Everbridge.  

We want to use the solution with Everbridge to become our incident hub for incident managers to collaborate on high-priority incidents.

The most notable improvement is in our time to respond. Traditionally, when we had high-priority incidents raised on our ServiceNow platform, the monitoring would detect them. Then a monitoring team member would contact others, take the incident assignment, and start working on a fix. Since we implemented xMatters, getting someone working on the call has gone from 30 to 35 minutes to about five minutes. That made a massive impact on our organization.

The solution helped to automate the incident notification process, and communication around incidents is much improved with xMatters, especially with the recent expansions in Teams. We can see callouts, updates, and whether callouts have been accepted or rejected, and it all goes back into our incident, so we can see what's happening almost in real time. Therefore, users are well informed of unfolding events, and the whole process runs more efficiently because the automation removes the manual element we used to have. 

xMatters helped us build workflows that meet our needs. I work for a major broadcasting company, and our most recent project was to create workflows to deliver an end-to-end callout solution for our parent company. This is important because I remember the solution before there were workflows, so it was more coding oriented, whereas now it's much more drag and drop. Coding skills aren't required to set up workflows now.   

The solution's workflows helped us to proactively address issues, as all the workflows we set up do precisely that. The guiding practice behind our workflows is to deal with specific use cases more proactively.   

The solution providing targeted, content-rich notifications reduced our response time, and that's our most significant takeaway from using xMatters. Response times are the most notable improvement from using the platform and integrating with ServiceNow. As mentioned earlier, we can get someone physically working on a callout in under five minutes, whereas it took 30 minutes or more previously. For a broadcasting company, when services aren't available, like pay-per-view, for example, 30 minutes has a huge impact.  

xMatters stood out to us during our research because of the versatility of its rotas, how we could set up various group rotas, different shift patterns, the ability to order devices and add personal devices etc. It's a much more flexible solution than ServiceNow, the in-house tool we also evaluated.

We use xMatters logs as part of our operations, and the logging capabilities are excellent. I use it a lot when building new functionality and troubleshooting. The logs are contained so we can separate them from other logs, which is helpful. I couldn't be without this feature in some cases.  

We find the UI to be very intuitive. 

We use the tool's REST API, which works well; it's very stable and efficient. When we first set up xMatters, we didn't have REST API, which was converted some years ago when it became available. The conversion was straightforward, and we've had no issues with it. It's a highly efficient product in this regard.  

The reporting functionality could be improved, though I know that's something xMatters, inc. is working on. For example, sometimes I need to go into the platform and find users who aren't in groups that have been created recently, haven't logged in and so on. Previously, this was hard work, but they added loads of filters, making it more accessible. Still, the ability to create custom-designated reports that I could run and schedule would be fantastic for me. It would be good if they keep improving the reporting functionality, as it can be somewhat restrictive sometimes.

There are a couple of improvements that xMatters could make to the incident hub, where we can manage high-priority incidents. More sharing capability between collaborating incident managers would be good to see, including the ability to whiteboard. That would allow them to share and sketch out ideas while looking for a solution.

Those two features are essential, and that's why we want to use the solution in conjunction with Everbridge because xMatters doesn't have them.

We've been using xMatters for about ten years. 

The tool is highly stable. In our ten years of use, we had one major issue, but that was a problem with Google Cloud that took out a lot of different systems. It wasn't an issue with xMatters, which was affected by a more significant problem. Aside from that one issue, I can't fault the solution's stability.

The product is very scalable. We had a hectic few years, but I've seen the improvements made in terms of scalability options, and it's to our detriment that we have yet to spend time looking into those.

We have over 2,000 licenses, 1,970 of which are taken, with 428 support groups using on-call across two systems, one for us and one for our parent company. Each support group has at least one rota manager with access to the interface to go in and set up the rotas, shifts, and particulars for their group. All users and groups are on the same instance of xMatters, even though the callouts are triggered from two different ServiceNow platforms. We have incident managers with elevated roles who can use Engage functionalities such as conference bridging and some extras. We have some admins building out workflows and various other users, including rota managers and standard end users spread across several countries.

The technical support is excellent; whenever I needed support, I immediately received an email acknowledging the issue. Then someone usually contacts me within 24 hours to help, and the support staff are pretty good, efficient, and know what they're doing. In terms of larger-scale projects, I've had consultants assigned to assist with the more extensive integrations, and they were excellent too. I rate them ten out of ten; they give me no reason not to.

Positive

We recently set up a similar solution to our own for our parent company, using the xMatters platform. The new Workflows feature made it much more intuitive to set up this time than it was ten years ago, so the initial setup is relatively straightforward.

The solution requires some maintenance but more from a licensing perspective specific to our environment. As we are charged for user licenses, the synchronization between users across the two different systems we have is another layer for us to consider. Sometimes, we end up paying for a license that no one is using, so we have to do some maintenance to fix that. Aside from some licensing maintenance, the workflows and inner functions run themselves.

Considering the main strength of the solution, the response times, we have seen a return on investment. The speed with which we have responded to significant incidents, like a pay-per-view system going down, has saved us thousands, if not hundreds of thousands of pounds over the years. We can get staff on a problem to get it fixed so much more quickly and efficiently.

The cost depends very much on the company's size and usage. We're a very high use case compared to many companies, so we had to consider licensing costs carefully. If we added all our users, that would be 30,000, and that's no good; we wouldn't have been able to afford it. For example, we had to put in customization to sync across on-call users. For the license per user, the price is very reasonable and comparable to ServiceNow when factoring in everything that needs to get up and running.

Considering the breadth of features provided by xMatters, it's worth the cost. It gives us everything we need, and there are still additional functionalities we're not currently using that we're licensed to use.  

Comparing the intuitiveness of xMatters with similar solutions concerning customizing on-call schedules, rotations, and escalations is one factor that encouraged us to go with xMatters. It is not only more intuitive but more versatile and flexible too, which is why we chose it. 

I rate the solution nine out of ten. It isn't perfect, but it isn't far off, either.

Regarding the intuitiveness and flexibility of xMatters when it comes to customizing on-call schedules, rotations, and escalations, it's pretty intuitive. We do a lot of proactive investigation into the system and monitor the solution, so we sometimes find a small number of users who set up their shifts every week when they don't need to. A handful of users don't find it intuitive, but when we show them how to set up repetitive shifts, they do. It's a tiny proportion of users we have to give some guidance to in this respect, however.

In terms of ease or difficulty integrating with other tools, it is relatively easy because of the experience we've gained over the years. We've always had help from an xMatters consultant for sizeable integrations. 

With less experience, and if I were trying to do it on my own, I wouldn't say integrating is easy but certainly doable.

When we look at the store, we can see the level of integration available with the product, and it's both extensive and impressive. We go with the integrations required by our use cases, we don't go out looking specifically for other integrations to use, but that's something we could consider doing. 

We used coding to expand the flexibility and functionality of the xMatter's workflows. The out-of-the-box solution comes with a plugin for ServiceNow, which provides the core elements to do a callout for an incident and assign an assignee to the incident. We had a use case for high-priority incidents where we needed a separate callout for the incident team. So, one for the assignee and the assignment group, which is out of the box, and a different callout to the incident manager and incident team. We needed the ability to trigger two callouts for the same incident, which was a custom requirement. We copied many original box scripts and modified them to provide a solution. 

The product didn't necessarily reduce Sev-1 incidents because the two are mostly unrelated. It helped us deal with them more efficiently when they occur, and the on-call schedules are its biggest asset. Getting to the right person on the right device quickly is critical for us.

When we decided we would go with xMatters, I did some online training and looked at a developer instance of the solution to get used to it. I then worked with a consultant to start building out and learned the system's intricacies. There's a lot of online documentation to help figure out the necessary plugins and roles, and I followed a walkthrough to get the plugins. We had a developer instance of the solution and a production instance, so we set everything up in the developer instance and then transferred it across.

I'm a big advocate of the product, and I recommend it. I've been working with it for ten years. We considered other solutions, not just in the beginning, but every time our contract came up for renewal, we've always gone back to it. xMatters does its core role brilliantly, and it's continually updated with new functionality and improvements. As a company, we have yet to find a solution that compares to xMatters.

I've used it in two different capacities. The first one is as a user where I've had to initiate notifications either to a large group of support teams or page individuals through the tool. I did that probably four to five years ago, and then in the last three to four years, I've been using it as more of an admin where I'm building out form scenarios and different communication vehicles for our command center staff.

The biggest improvement is from the standpoint of making sure that we can use the 911 feature. Our company is realizing the benefits of using xMatters as a 911 calling feature internally. The way we use xMatters is the way you would use the 911 feature to be able to contact a call center and get the police, the fire department, and the ambulance to your house within a very short window. It provides the ability to do that. Five years ago, we had maybe 30 911 related calls a month, and now, we're averaging over 400 911 related calls a month. A lot of it is because our organization is growing so fast, but xMatters has that ability to help us when there is an emergency or an event where we need to pull in multiple teams. We can do that very quickly with xMatters.

It gives us every ability to customize as we need. We don't really have any crazy ideas of what we were expecting from the tool. It lets us cover our largest teams with 50, 60, or 70 people in a team. It lets us have multiple escalations within those teams. Multiple shifts with in the groups allow us to see any gaps or scheduling conflicts and even lets us assign a backup on-call when someone is scheduled off due to vacation or an illness, a backup solution is already there in the tool. So far, we haven't seen anything that we couldn't do in the tool related to scheduling and on-call coverage in groups.

We have currently integrated it with MS Teams as a conferencing and chat solution. We have it integrated with OMNIbus and Splunk, which are alerting tools. So far, I haven't had any problems integrating it with other tools. They give us a lot of options. We can integrate it manually by adding the links as drop-down options to integrate with those conferencing bridge lines or the MS Teams chat links. If we want to integrate through bots or through other ways, they give us multiple options. Currently, we're using a lot of manual integrations. So, we're uploading links and allowing individuals to select the appropriate integration, and then from there, they can select which conference bridge or chat they want to select from drop down values. So far, it has done what I need it to do.

We have over 350 notification vehicles for the applications that we support, and we've automated 8 of those with our alerting tools. It has helped with our more highly visible, and what we consider critical, applications. Instead of having someone to detect the alert and then send out a manual notification, we allowed our integration with OMNIbus and Splunk to automatically trigger those alerts, which has saved us 5 to 10 minutes. This allows for teams to start troubleshooting an event 5 to 10 minutes faster than they normally would. We're seeing that type of integration with alerting grow. We've received 5 to 7 new requests for automation notifications this year. So, that's going to grow. At this point, everybody who is using it really likes it. I can tell that we're going to be moving in that direction of having more automated notifications in the future.

It allows us to be aware of an issue faster. It allows us to respond and start troubleshooting an issue faster. As a result, our customers and our internal support teams are probably happier that events go away or are resolved at a faster rate.

It helped us to build workflows that meet our needs. The workflows allow us to push out multiple communication vehicles to our command center or support teams. If we didn't have the workflows that are built into xMatters, it would be hard for us to push out these large complex communication vehicles. The workflows allow us to use the same properties, same scenarios, and the same forms to push out and streamline the communication vehicles that are available to our staff. If you had a hundred people using a hundred different pieces of paper, it would be hard to maintain, but if you can have everybody using the same notebook and using the same cheat sheet, it gets easier. The workflows are like those cheat sheets. They make it faster, and they make it easier, and when we make an update, it's cascaded to all the forms and the scenarios as part of that workflow. So, it streamlines our work from an administrative standpoint.

It has reduced the response times in our organization. Since I've been here, problems get resolved faster. Because of xMatters' automated notifications and the ease of use, people can send out notifications and get together faster to solve problems. 

Its on-call schedules and streamlined escalations helped to reduce Sev-1 incidents in our organization. 

The most valuable features are the ability to have groups and then have an on-call rotation in the groups. Outlook lacks both these features. Outlook gives you the ability to contact an individual or groups, but you can't contact them based on an on-call rotation, and you can't have built-in timing escalations inside of that. xMatters gives you the ability to do that, which is important when you have 50 or so people in a team, but you only want to contact the person who is on-call. You don't want to create unnecessary noise with your large support teams. xMatters allows you to page the right person who is on-call versus just creating excessive noise for a group. If you send an email via Outlook to 50 people, all 50 of them have to get it when maybe only two people are responsible for actually working on that problem. The other 48 people would consider that noise. xMatters has the ability to deliver it to a targeted audience within that group.

In terms of restoration, if you delete something, or you have multiple users that have the ability to delete a group, a user profile, or a workflow, the ability to restore it within the GUI is not available. A button to go back to a good point in time would be really nice. A lot of other tools have a better backup and restoration solution, but xMatters is a little bit short on that. They have a 95% backup restoration solution available, but the other 5% requires manual effort. We would like to be able to just push a button and say, "I want to restore this piece back to this date," but we can't do that with the tool right now.

I use its logs on a regular basis. It seems like it logs everything accurately. To be able to pull the data from the logs via the GUI is a little cumbersome, but it does give you the ability to export into Excel, where I do have the capabilities of doing pivot tables and some advanced searches within Excel. 

I have been using this solution for over five years.

We haven't really had any issues. In the last five years, there has been a 15 to 30 minutes outage here and there. It's usually because of an cloud issue or issue related to single sign-on doesn't allow us to access the tool during the outage. From the tool standpoint, it has been pretty dependable, and we're fairly pleased with that.

The number of users that we have across the whole organization is around 6,000. They could be using it in three different ways. One as administrators, where they're administering a group or workflow. Another is an initiator of a notification, where they would go into xMatters, fill out the form, and then submit or send the notification. and then, there is also a large audience around the world that is a recipient of the notifications. They are the users who only receive notifications so they can be aware of an event or participate in troubleshooting activities.

Their tech support is pretty good. There is an online account where you submit everything online. The user interface for that lacks a bit of quality. It has a whole bunch of open fields, but the team that receives the email stating the problem and provides assistance does a really good job. 

Their communication is a little overboard sometimes because when you send the email, you get an auto-response saying that they got your message. Then, there's a live agent that says that they got it and are working on it. After that, within 10 to 15 minutes, you actually get the response that you're asking for. So, there is a little bit of extra noise. You send one email and you get three back, which seems a little excessive. 

I would rate them an eight out of ten. In some cases, I'd like to not have to go back and forth so many times in an email. I'd like for them just to say that this is a complicated scenario and if we can schedule a call or a screen-sharing opportunity to troubleshoot, but they prefer to go back and forth in multiple emails, which delays resolving the issue that we're having. That's just a learning curve on their end for them to figure that out. 

Positive

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.

I was just a user of the tool when it was deployed. I wasn't an admin. To start using the solution, there was training. We had to learn how to use the tool by setting up the workflows, forms, and scenarios. We also had some advanced integration questions for which we had to learn how to use it. We met with the vendor, and they provided us with a high level of support.

In terms of maintenance, because of the lack of a restoration and recovery solution, we do perform a lot of manual backups of components within xMatters. So, we're prepared in case something were to be deleted, and that would be the biggest maintenance activity.

There is a return on investment. Being able to restore internal and external customer applications and services has pleased our customers. It has given us the ability for a higher level of service to our customers. So, there is a return on investment.

I'm not really involved with the cost standpoint. I've only heard rumors of how much it costs. It seems to be on the higher end from a cost standpoint.

My team does not use its REST API. I know that there are other admins who use it, but not my team.

I would rate xMatters IT Management a seven out of ten. The backup restoration solution is a big piece, and that's the main reason why I would rate it a seven.