xMatters Reviews

We use xMatters to handle system alerts. Generally, we use xMatters as an automated process in particular systems. For example, if the source detected an issue, it will use xMatters to alert the team member to resolve that issue.

xMatters is utilized as part of our system monitoring and alerting.

From the support team side, my focus is more account management, which is my primary task.

The end user accesses xMatters logs. As the support team of xMatters, we use their logs for troubleshooting, e.g., to see when an event is triggered, the process of that event, who was notified, and whether the delivery of the message was successful or not. If we cannot resolve a user's inquiry, then we will always work with xMatters' support engineering team to conduct further analysis.

Based on my support experience, it seems like our end users can integrate xMatters into event notifications and other applications successfully. Occasionally, we get support inquiries, essentially trying to understand how a particular functionality will work. If the functionality failed to work as expected, then we have always been able to get solutions from xMatters' support engineering team.

Here and there, we have made use of coding to expand the flexibility or functionality of xMatters workflows. I have created some custom workflow setups. For example, as part of account management, we do a scheduled process that will notify all the inactive users by sending out a notification via xMatters. It will ask them if they still need their account or not. Overall, the workflow is very simple, and the one that I built is not complex.

xMatters supports our usage and what our end users are trying to accomplish. As long as all our end users are supported on their operations, then as a support team, we are good with the product. 

The feature that I have found to be most valuable is the entire alert notification configuration, having an external system to trigger events that will process the alert to the supporting team. If a system is down, then you need to get it attention. Sometimes, it cannot wait until the next day. Therefore, how xMatters provides this type of integration is critical.

It is well-rounded. An individual will have to learn the UI. The UI and controls are easy to set up. 

The end user team has quite an extensive customized integration with other applications. Thus, I can only assume that our end users are heavily using xMatters.

I would like some minor UI changes. I believe I filed some enhancement requests with xMatters. For example, in one area, they have some way for you to look at a particular functionality with different sets of reporting UI. However, that same reporting UI is not yet available with some other functionalities. Essentially, in their existing functionality, the xMatters application does an excellent job, but in other functionalities within their UI, they don't have that. On the back-end, they are related. Instead of one click where you can see everything, right now you need to go to different areas to access similar information. It would be nice to have everything in one place. While they have an excellent element A, I am hoping that they could just simply make that feature also available in their element B.

I have been using it for about a year and a half. 

I believe my company has been using xMatters for quite a while. About a year and a half ago, the global infrastructure application support team took over the ownership, supporting the product usage. So, I have been doing functional support for this particular application for about a year and a half.

The xMatters application is very stable. They also always keep the customer up to date with advanced notifications, e.g., if there is any scheduled system downtime. Usually, those downtimes are minutes. However, they will notify their clients when those things happen and are always able to provide the root cause, such as what took place and why the system was impacted. So, as a customer of xMatters, we never get left in the dark, trying to see what is going on.

All the maintenance is done from their end. They also proactively reach out when there is something causing some type of configuration abnormality in xMatters, which would be caused by perhaps one of our configurations. They will proactively reach out, and say, "Hey, you probably want to get in touch with your end user and help them fix it accordingly." However, that is really rare. In the past year and a half, this happened just one time. There is one team who has a workflow that contained an element that is no longer supported, and that was resolved very quickly.

xMatters is extremely scalable and extensible. The design gives you a lot of freedom on the applications that you want to integrate with xMatters. Therefore, they already have a large inventory of different application templates that you can utilize. 

There has never been an interruption because the traffic and the volume are high. This means that our external system can properly be integrated with xMatters, which will handle an alert without delay nor compromising the quality or timeliness of our delivery.

Our end user can be a group supervisor, meaning that they are the people who manage the group and on-call rosters. There are also developer roles. Those are the users who are doing workflow with development and integration setup. Lastly, there are just general users who are part of the on-call roster. They will get notifications when something happens that they need to take action against. 

xMatters doesn't own our content. They provide support activity, assisting our users in configuration, but xMatters itself is very intuitive. 

I would rate the support as nine or above (out of 10). xMatters' support engineering team is bar none with the service that they provide. It is always a pleasure working with them because they get stuff done. Other vendors need to use xMatters' support model as the model to follow.

They are very detail-oriented. They are always clear and concise. I can share their findings with my end user because they provide them in layman's terms, even non-technical end users can understand them.

Positive

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

We went through the training material. It is like learning any other application. For example, if you are going to be doing workflow development, then you need to understand the workflow design and UI. Same as if you are going to set up a group, you need to know how to set up on-call scheduling and learn how to manage your team's roster for the group. 

Overall, it is very intuitive and straightforward. xMatters is one of the applications that does provide a lot of online documentation, in which they do an excellent job.

xMatters on-call schedules have helped to reduce Sev-1 incidents in our organization. This is based on users using the latest incident alert functionality to get their activities done.

You should perhaps arrange an evaluation or trial to just test it out. Get your feet wet. That is so important. If you don't try it, then you won't know. 

In regards to all the functionality xMatters provides, I learn every day while working with end users. I like to say that I would never consider myself as an expert of tools, instead I am a jack-of-all-trades. That is why my learning will never stop.

I would rate them as 8.5 out of 10 since no application is perfect.

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.

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 have two instances of xMatters. One is for IT alerting, and one is for business continuation. 

We leverage our IT instance to notify different IT groups, such as system administrators or web developers, and then escalate an issue to a specific group.

We utilize it for disaster recovery to be able to send out messages to either the entire company or a more granular group of individuals, such as a specific location or specific departments.

We're able to communicate better with specific groups or offices. We didn't have that capability or granularity before. It has helped in that regard.

Automation of our incident notification process has increased our capability to respond. We can not only alert a whole group of people. We can also configure escalations so that one person is notified, and then it continues up the escalation if it is not responded to.

It has helped us to build workflows that meet our needs. It is important for us because it just helps create additional efficiencies. If we can configure workflows, that typically helps us be more efficient when there is an issue. xMatters workflows have helped us to address issues proactively.

The targeted and content-rich notifications have helped to reduce response times in our organization, but I don't have the metrics.

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

It has been useful for IT alerting and business continuation.

When it comes to customizing on-call schedules, rotations, and escalations, it is very flexible. There is only one thing that we've not been able to do, but if a capability is not there, you can always enter an enhancement request. They're very interested in what we're doing as a customer and what we're looking for. It is very easy to use and intuitive as compared to other similar solutions.

We have integrated it primarily with Jira. We use Jira for our help desk system, and then we can escalate a help desk ticket to a specific group of people for our IT instance. For example, if there was an issue with the server and a ticket was created, we could escalate that to our server team. The integrations that we have done were good and easy to set up.

We use xMatters’ REST API, and it is easy to use. 

We use xMatters logs as part of our operations. If needed, we do review the logs.

Additional built-in integrations with other applications would be an area of improvement.

I have been using this solution for just over three years.

Its stability is very good.

Its scalability is very good. We probably have about 20 to 25 uses in total. For the IT instance, it is our IT team that is using the instance. For business continuation, it is our HR team. We have plans to increase the usage of the product.

It is very good, but there is always room for improvement. Their support can be improved in terms of the initial response times and getting an engineer on the line. I would rate them an eight out of ten.

Positive

We didn't use any other solution previously.

On the IT instance side, it required preparation in terms of figuring out the groups of people to whom we wanted to send the notification. It involved defining and building those groups. On the business continuation side, it was primarily importing our user data so that we could properly communicate with specific locations and/or teams of people.

In terms of maintenance, it is a SaaS solution. The only real maintenance required on our side is to make sure that our end-user data that is imported into the solution is correct. We export our user data from one system. We then make sure that it is formatted correctly, and after that, we import it into xMatters. Its maintenance takes about 20 minutes per week.

We have seen a return on investment.

It seemed comparable or more reasonable than some of the other solutions, at least when we evaluated it. There are no extra costs in addition to the standard licensing fees.

Its cost is good, given the breadth of features provided by xMatters.

We did evaluate a few different solutions prior to making the decision to implement xMatters. We went with xMatters because it seemed like it had more flexibility and capabilities, and it could also be integrated with our ticketing system.

I would advise understanding what you're trying to gain out of bringing in this product, and when you do, be ready to get it configured. There is a little bit of lead time, but configuration and setup are fairly easy.

The biggest lesson that I have learned from using this solution is to be organized. If you're using it for emergency alerting, then be ready for whatever your needs are.

I would rate this solution an eight out of ten.

We use it as an integration point with our monitoring solution, which is Micro Focus Operations Bridge Manager. We also have an integration point with Micro Focus Service Manager.

xMatters helped to automate our incident notification process. We generate incident tickets right from our alerts. That ability is excellent because we're able to respond immediately and indicate that someone has taken ownership of the alert.

We also use the coding to expand the functionality of xMatters workflows so that we can ingest information from a security solution. That will then generate an incident in Micro Focus Service Manager.

In addition, we have seen reduced response times, and the streamlined escalations have helped to reduce priority-one incidents in our organization.

The most valuable feature is getting alerts out to my user base. xMatters is the only solution that I know that has robust scheduling, calendaring for groups, and that provides very good delineation of who gets alerted and on which devices they receive their alerts.

It provides very robust and flexible means for scheduling and escalation. We use it quite extensively for making sure that we can schedule groups and the individual who is on call within them. We can make sure that, during office hours, everyone on a team receives alerts, but only the on-call person receives them after-hours via an SMS message. We use the calendaring quite extensively to make sure that we can schedule our shifts. Most of our groups include some form of escalation so that if somebody doesn't respond to an alert within prescribed timeframes, it will then send an alert to someone else.

The xMatters REST API is also very good when it comes to process and information customization.

I would like xMatters to provide users with the capability of administering it on their own. I do a lot of hand-holding with them.

I have been using xMatters IT Management for 11 years.

The stability of xMatters is excellent. It's probably the most stable piece of software that I'm responsible for.

To my knowledge, it's extremely scalable, although we have not scaled it at this point.

Currently, we have 170 end-users. 

Everbridge's technical support for the solution is better than excellent. Every one of the support analysts that I have dealt with for the last several years has been able to provide a very quick response and a resolution to any problems that we've had.

Positive

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

In terms of the preparation needed to start using xMatters, we had to do a full security audit.

We get value for what we pay. I'm not looking for a return on investment, I'm looking for functionality. The value is in the alerting functionality.

When it comes to integrating xMatters with the Micro Focus solutions, I wouldn't say it's excellent, but it's certainly more intuitive than most integrations that I've done.

Overall, I recommend xMatters regularly to people. I don't recommend other solutions.

We have 3 XM instances and have integration between the below environments:

• XM- BMC ITSM for Incident Management
• XM- BMC ITSM for Incident Management 
• XM- BMC ITSM for Change Management
• XM- Service Cloud
• XM -XM instances

All the instances are a combination of on-premises and SaaS services.

The primary role is to notify the appropriate resource which reduces the time to notify and further reduces the time to resolution and overall MTTR.

When a Sev-1 is generated, the alert gets generated to the appropriate support group which leads to contacting the right SME to initiate the MTTR process.

The initial stage of identifying the right SME was a challenge. This led us to delay notifying the right SME and start working upon the restoration of service.

After implementing the solution and updating the groups/on-call list we have seen a huge volume of increase in the Time of React. This helps us to alert the right resources within a fraction of seconds (after the alert is generated) which allows for quick notification and a faster restoration process.

The request also gets assigned to the resource which avoids SLA breaches.

There are multiple features within this product that help, including:

1- Integration between multiple products (makes it easy to notify the alert)

2- Seamless process of on-boarding resources on the XM platform

3- Groups creation and resource mapping to the appropriate groups

4- Easy steps to set up the on-call schedule

5- The on-call list includes an auto-rotation feature which helps us to avoid visiting the app to change the on-call list week by week

6- Simple features create flow sets and build APIs for integrations

7- Reporting that helps to get the right volume of alerts

8- Dashboards that help to view the status of the alerts

9- Logs in the alert also help to identify the details and root cause

1- Duplicating the Groups

2- Weekly/monthly notifications to the admin on the licenses consumed vs available

3- Bulk update of groups

4- Early product enhancements should be added in the next sprint/release

5- An additional knowledge-sharing program could be helpful and part of the demo workshops (right now, these only provide partial information)

6- Identify real-time issues and have OOTB templates related to use cases

7- BEing able to update the same event, rather than creating a new one which would avoid confusion on multiple events created for the same alert

I've used the solution for 4 or more years.

As of now, we haven't had any downtime - the app being a SaaS platform. It clearly mentions the Infra and the service provided is 100%.

We did not use a different solution previously.

We would advise new users to reach out to the XM sales teams for a better quote.

We did not evaluate other options. 

We have three instances of xMatters. One is for customer support, one is for our internal IT, and the third, that we recently procured, is the SaaS version.

We have integrated two of our xMatters instances, the IT instance for ITSM incident management, and the SaaS version. We also recently worked on integrating customer support between xMatters and both instances, so that xMatters can be triggered from the SaaS instance and there will be a notification in the customer support instance. And vice versa: An alert from customer support will reach out to the on-call in the SaaS instance. And now we are working on integrating xMatters with change management and SaaS. In addition, we integrated xMatters with Salesforce.

At one time I was working in our global network operations center. We had a few difficulties in reaching out to the on-call resource. I would call someone only for that person to say, "Okay, I'm not on-call this week. You should call this person," and that person's number was unreachable. Then I would have to call the first person again and he would say, "Okay, now call this person," and he might also not be the right person. It was a time-consuming process and there was a delay in dealing with the service disruption. Implementing xMatters has helped us to identify who the on-call person is, and the built-in escalation really helps.

Managers can also get an idea of which on-call resources acknowledged an alert, and whether it was escalated to the next level or the third level.

Also, the targeted, content-rich notifications have helped to reduce response times, although we haven't measured by how much.

We have only integrated our Sev-1 incidences. Once a Sev-1 is generated, an xMatters alert is automatically triggered and the on-call person acknowledges the event. With that acknowledegment, the incident's status is changed to "in progress." As a result, responses to incidents are at 100 percent. We also have a checkpoint. When there is an event, a NOC engineer reaches out, every 15 minutes, to the person who has acknowledged the event, about whether there is a service disruption or not. With the quick responses to alerts, we have time to figure out what our outage notification or disruption message will be to our end customers. All of this definitely helps us to reduce the communication involved, as well as expedite the restoration of service. 

xMatters is helpful for getting the right on-call resources. That is a key factor. It is also very user-friendly, and just a little documentation helps you to understand things such as how on-calls are configured, how groups are configured, and how users update their on-call devices.

We're also able to specify messages for the different channels, such as text messages, voicemail, or email. That is quite helpful for us.

In addition, xMatters' reporting capabilities help managers to identify the peers and escalation that we have configured. It helps them see how many times an on-call either did not receive an alert or escalated it.

Another key feature set that xMatters offers is the API calls through which you can trigger xMatters. Because every application has its API, we just have to set up small workflows.

We also use xMatters logs on a daily basis. All incidents are created in ITSM and the logging capabilities are easy to use. We have integrated our xMatters with Okta. As a result, the authentication process takes care of the username and password. We haven't provided our users a bypass link so that they can directly log in to xMatters. Users have to log in using their Okta authentications.

With xMatters we have the flexibility to grant permissions to managers so that they can update their on-call schedules. They can change who is available in the next week, who is on the roster, et cetera. Managers can decide which person will be working on which shift. Some of our teams work 24/7, some work 24/5, and a few of our teams work 18/5. Managing all of them is a tough job and we addressed it by having the managers update their own on-call lists.

We have integrated two different xMatters instances. When something triggers in xMatters, we get a message in that instance about who responded, the device type, et cetera. But if we try to trigger it to a different instance, we don't get that kind of information. For that scenario we have built a workaround to get the details of the event, and that we have received a response for it. That's one of the major things that could be improved.

Another issue is related to the reporting. We have to know what keyword to search for. When we type something in, we get a few suggestions. If the suggestions are not enough, we need to go back to the specific event message and look at the actual event, and learn what needs to be updated based on that. We get that information from the Properties tab.

Thirdly, we have to create an Excel sheet for onboarding users and then upload it. But if an employee resigns, we don't have any checkpoints to validate whether the user is still active or not. We have to do that manually every week: Check who has left the organization, and do a cross-check on whether that person had any licenses or signed in to xMatters. If so, we have to make that profile inactive for a month and then release the license.

Finally, I get regular updates on the new features that are being released by xMatters. If they could provide a short presentation or video on these new features, and how we can leverage them based on our use case, that would really help.

We initially procured xMatters back in 2017 or 2018. We were looking to share these kinds of ideas with our internal and external customers who use xMatters, as well as ITSM.

xMatters is stable.

I only recollect once that we needed some maintenance, but that was also part of the 99 percent availability. The maintenance was done with zero downtime. I don't recall that we have had to do any maintenance on xMatters.

In terms of scalability, I'm managing two different instances of xMatters and someone else is taking care of the customer support instance. I believe that instance has 9,000 licenses. For IT we recently purchased 30 more so now we now have 180, and for our SaaS instance there are 200.

Whether we will increase our usage of xMatters will depend on how our business develops.

The technical support team is really helpful. They know what we are asking and what we are looking for. They don't work by saying "Step one, step two, step three." Whenever we submit a ticket, even if it is a P3 or P4, we immediately get an acknowledegment that they are reviewing our request and that they will get back to us. It's not like, "Okay, it's P4, let's respond after two or three days." Overall, their tech support has really helped us. And if the requirements or the scope go beyond their capabilities, they will involve our customer relationship manager. Once he is in the picture, if required, he will tell us we need to involve professional services.

But so far, there has not been an issue that a support person was unable to resolve for us. Some of the time there has been some back-and-forth communication, but in the end, we have been provided with a resolution.

Positive

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

As this was a new application for us, we were not aware of what might need to be done. The professional services team was engaged at some point and, through them, we got a few ideas about how this would help us, how we could integrate it, how the user profiles are built, how the groups are created, et cetera. 

The process of integrating xMatters with other applications was not too difficult. We already have the GIT files readily available, so it was just a matter of updating the scripts, connecting the dots, and it was really helpful in building the workflows.

The issue that is impacting things is the licensing. The features are really good. The solution really helps us to find the appropriate person, per issue, and to resolve each one as soon as possible. But what makes things difficult is the licensing. We have to manage the number of users we onboard, and we need a buffer of 10 or 20 licenses because in an emergency or crisis situation, we might need all those buffer licenses.

Still, we have definitely seen cost savings when we are restoring a service disruption. When a Sev-1 is initiated, xMatters is triggered and calls the right person and he acknowledges. On a weekly basis it saves us between $100 and $200.

Every customer would like a free ride, of course, and being a customer, I definitely feel the pricing is too high.

A caveat here is that initially we procured 150 licenses and we have almost 1,500 users in IT. We had to come up with a few ideas for determining which users get a license and which users don't need one. Due to the limitation of the number of licenses, we were unable to integrate the user profiles with Active Directory. 

Also, having that many licenses versus that many employees won't help us. It would be good if there was a feature where we could trigger all the users we need in a single go. That would really help in a crisis situation.

We didn't evaluate any other options. When we had the xMatters demo and we felt that it was the right product for us. The integration ability was the main aspect, as were the user profiles, the on-call list, and the delivery channels for messages. All of those really helped in our decision to purchase the xMatters solution.

The biggest lesson I have learned from using xMatters is that end-users have to manage their own profiles and know their availability for the on-call schedule. Also, if someone is not available to be on-call, the absence/replacement feature in xMatters really helps. The replacement enables us to know who is replacing whom, from when to when, and from which team. And with the recent launch of workflows, we can build our own workflows. I reviewed a few videos on integrating Teams or Skype with xMatters and that looks like a key feature.

The documentation from xMatters, in general, is very clear and the support is very helpful.

I use xMatters on a day-to-day basis. I have an eye on all three instances we have. I know which user is replaced by which user. And whenever the support team reaches out to me saying, "This event was triggered to me, but it should not have been triggered to me," we have all the logs to help us identify why that event was triggered to that person or why it didn't trigger to a given person. If we need any more help, again, the support team is there. We just submit a request and we get assistance. 

It has been a good journey over the last three years, getting more details about, and insights into, the product. It really helps us.

We use it mostly for major incidents. To contact, we use the group on-call schedule feature. We use it to communicate and notify our IT stakeholders and executives.

We are about to use it for incident alerting on applications. We will first start using it for one application, and then we will see how it goes.

Previously, we used to do everything manually. We used to call our on-call resources manually. If we wanted to inform someone, we used to use Outlook email. Now, it is much easier because we're using the subscriptions based on location and affected services, which is amazing.

We have the Inform with xMatters feature and the Engage with xMatters feature. We are also using the major incident feature where it sends SMS and text messages. We use it only to communicate with the IT leadership, and it is great. Previously, we used to send text messages manually using our cell phones. I'm not in the US. I live in Panama. So, when I send a message, it normally gets a different number. So, no one knew how to add my number or whatever number they get from my cell phone to their safe contact list. Now, we have a specific phone number that doesn't change. So, they know who is calling, why they are calling, or why they are getting messages. That's very good. The customization of those text messages from the web service is also great.

It has helped us to build workflows that meet our needs. The ServiceNow workflow is very good. The Major Incident Best Practices workflow is another one. For our next application, there would be a new workflow that I need to create. We are also using the Emergency Change Management workflow, but the most important thing for us is major incident management. We use it for all Sev-1 and Sev-2 incidents and almost everything related to major incidents.

xMatters workflows helped us to address issues proactively. From the Major Incident Best Practices workflow, I created a workflow directly to Teams to post a notification on our Teams channel so that everyone who isn't subscribed on xMatters can see the notification that we're sending out. It helps a lot as well. I did it myself, and it was pretty easy.

xMatters provides targeted, content-rich notifications to reduce response times in our organizations. It has reduced the response time by at least 50%. Previously, we used to call people manually. 

xMatters on-call schedules and streamlined escalations have helped us to reduce Sev-1 incidents in our organization. We can contact any person. There is a 20% to 25% improvement because Sev-1 incidents are more related to the vendor. They are not internal issues.

The on-call schedule that they have for groups is amazing in terms of how it works and how it triggers. You don't need to do anything. You just upload the users, and you have the calendar of the schedules. It is amazing how it works and how easy it is to work with this feature.

It is very intuitive for someone who is not technical. Some of the groups that we have are not technical, and as soon as they get on the mobile app, if they want to change on-call with someone else, they just quickly change. It is very intuitive, which helps a lot. 

We have integrated it with Microsoft Teams and Cisco WebEx Teams. We have also integrated it with ServiceNow. It is not at all hard to integrate it with other tools. It is very easy to integrate. You just need to follow the steps that they have on the screen, and that's it. I believe xMatters can integrate with a lot of tools. The problem that I'm seeing on our side is that we don't use most of the tools. Our main ITSM tool is ServiceNow, and I have already integrated it. I'm trying to figure out how to integrate custom applications that are only used at Brinks.

We use xMatters REST API for ServiceNow. It is very good. I haven't had any problems so far with that.

The integration with Inform with xMatters is too customized. It should be a little bit more friendly.

When you are not using the conference bridge from xMatters and you are using an external one, it is a little bit hard to get the person whom xMatters calls to jump directly to the external bridge. They need to hang up the phone and then get to the email to get the URL so that they can jump on the bridge. There is no direct connection from xMatters to that external bridge, but I understand that part of the business.

On the web version, the on-call schedule is a little bit more technical. When you're creating the on-call schedule, you need someone who actually knows the product to create those. The problem is that we have not been using on-calls. Before xMatters, we used to use Excel Sheets. So, it is very complicated to do an on-call and figure out who's on-call. I know that I'm trying not to override one with the other one. So, I don't know if that can get better, but if they can, I know they will go there. They are the ones who are going to figure it out. They're very good at that.

We have been using this solution for almost a year.

Its stability is great. It is almost 99%. Everything works as expected, and I haven't had any issues with them.

Its scalability is great. I haven't had any issues. We have 76 technical users using xMatters, and we have around 250 to 300 basic users who are only getting notified by email.

We are using less than 10% features that xMatters has right now. We have plans to enable the incident management feature. As soon as we do that, I believe that the user or technical teams would have more visibility. They are reluctant to use ServiceNow, and this way, they can see that they have an incident, and it will probably give a better experience to our end-users.

In terms of integration with the rest of the applications, we're going to start with this new application. We have a lot of monitoring tools, and if we do everything right, as soon as ServiceNow gets an incident, we can trigger an event instead of waiting for an end-user to advise that something is happening. Currently, our monitoring tools are using actual people to monitor the queue, alerts, and other things. It is not as automatic as it should be. So, we are using less than 10% from xMatters.

They have been wonderful. They are great, and they helped me with everything. They are very knowledgeable about my environment. Their response time and everything is very good. I would rate them a 10 out of 10.

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

It is a cloud version, so they do all the updates and maintenance. We didn't have to do any preparation to start using it.

I implemented it with xMatters.

I would say we have got an ROI, but I need to do the document report.

We're currently per license. We're paying around $44,000 per year for 80 full users and 300 standard users. For a new implementation, we also need to pay for an expert.

We looked at Evergreen. I know that xMatters merged with another company, and we tried that one as well. I don't remember its name. We settled on xMatters because of the text message feature. We wanted to see everything in a single box on the incidence, but the other applications were divided into boxes. The text was too long, and we didn't like that. 

I would advise others to ask for a PoC to understand the product to make sure that's what they're looking for. They should also check if they're going to use the text message feature and the calls. They should know how much they are going to use and if it is covered with their contract. That's applicable to most of the companies because that's an expensive service. 

I would also advise others to pick all xMatters trainings. There are three to four minutes ones. They help you to understand what you can accomplish from the application.

We have been using xMatters mostly to communicate and engage. We are going to use xMatters logs as a part of our operations. We're going to implement it for new applications. The implementation would start next week, and it is pretty simple. We're going to use email-based alerting. So, we only need to add the xMatters email there. The rest of the workflow needs to be added in xMatters directly. It is pretty easy because that application doesn't have API connections.

We haven't automated our ticket incident notification process because we have some challenges on our side, and we're still trying to get better at incident management. We're trying to change the culture before we enable that feature.

We haven't made use of coding to expand the flexibility or functionality of xMatters workflows. I haven't gone that far. We're mostly in the workflows and the flow designer.

It has not increased the application release rate, but everything has gone as expected.

The biggest solution that I have learned from using this solution is how to automatize the communication and engagement with the IT team to improve the mean time to resolve incidents.

I would rate xMatters IT Management a 10 out of 10. It is awesome considering the breadth of features it provides and the cost of the solution.