xMatters Reviews

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.

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 use it for IT alerting. It is used to alert our monitoring solutions to call out on-call support. That's the primary use case for which we've had it here for a number of years. We also use it for major incident communication to subscribers.

It used to be on-premises, but we migrated to their SaaS product five years ago.

For our major incident management, it has expanded what we can do in terms of the format of the communication. People can subscribe, and they can receive delivery on multiple platforms, whether it's a voice message, email, or mobile app message. It enables us to deliver the right communication to the right people in the format they want.

We've integrated it with the Interlink software event management solution. Just recently, we have integrated it with Microsoft Teams, and we've also integrated it with a number of internal IT operations systems. 

They have made massive improvements over the last few years in terms of integration. Previously, we would've had to engage xMatters formally to get an integration built, but now, they just appear out of the box. The integration possibilities that xMatters offers are very good. There are a lot of integrations that are built within the applications and are just plug and play, which is massively beneficial for us. xMatters can easily integrate with the main IT operations solutions provided by the key vendors in the IT operations world, such as Splunk, Slack, and Microsoft solutions. It has got out-of-the-box integrations to all of those.

xMatters is very good at quickly rolling out out-of-the-box integrations for new software, which has enabled us to onboard applications quicker than before. Every six months, a new application comes out that trumps the previous one. They have been very good at being proactive themselves and making sure that they are on top of the market. They're very good at understanding what the key applications are and making sure that they have integrations built for those.

We use xMatters’ REST API. It is very easy to use. Utilizing xMatters' REST API makes things a lot slicker and a lot simpler.

It has helped us to automate our incident notification process via subscription. We've been able to integrate it with our incident reports. From those incident reports, we can ping a request into xMatters to create a notification that can then be automatically sent out to subscribers.

It quickly gets the communication out to a targeted set of users. So, we're not spamming people. By getting the messages out, people can engage with us if needed. They can read valid updates, and if they need to engage with us, they can engage quickly.

It has helped us to build workflows that meet our needs. I've taken a step away for a few months to understand exactly how any of that works, but we've been able to build workflows for our organization with minimal help from xMatters' technical services.

It requires minimal coding. The benefit of xMatters is that you don't need to do so much coding. A lot of their integrations are out of the box. We have made use of coding, but the amount of coding we need to do to build successful integrations and workflows has reduced significantly, which is a positive thing.

We made use of coding when we needed major-incident management communication, specifically for our cloud providers. We had to build workflows specifically to notify people about issues with cloud services. So, we had to do some custom coding to alert our internal cloud consumers.

The expanded flexibility or functionality due to coding workflows has affected our operations in a positive way. It has enabled us to create different communications for different communities and expand our portfolio for not just internal communication but also external communication.

The targeted, content-rich notifications have helped to reduce response times in our organization. We're now able to deliver the content on different platforms. Previously, we were able to send or receive voice and SMS communication, and we've always been able to receive notifications via email, but with the mobile app, we're able to send better information within our alerts. We're not restricted to so many characters within the notifications, and the format has improved. People can respond with different responses to different types of alerts. So, they're not just acknowledging an alert; they can now acknowledge alerts and send them to another person or send them to another group. It has enabled us to get notifications out with more information. We can enrich our notifications with better information and better response options. If they need to be escalated, we can escalate things quicker.

The IT alerting and call-out features are most valuable. 

It is very intuitive when it comes to customizing on-call schedules, rotations, and escalations. It is head and shoulders above other products when it comes to configuring on-call schedules and managing your rotas, devices, etc. Massive improvements have been made during the lifespan of the product in that area.

A lot of the issues that we've had have already been addressed. However, they could be clearer with the actual throughput and the costs. The throughput that we signed up for was a lot lower than what we needed, and we had to pay a lot more to get the throughput that we needed.

I have been using xMatters for more than 10 years.

Its stability is very good. We very rarely had issues. They could have also been of our own making because we occasionally do flood the system with alerts because we get event storms that end up spawning thousands of alerts, but generally, the product is very stable. It very rarely lets us down.

It's very scalable, but because we are such a large organization, when we originally signed up for the current contract that we're on now, the throughput that we signed up for was a lot lower than what we needed. To get the throughput that we needed, we had to pay a lot more than what we originally costed for, but you get what you pay for. We handicapped ourselves by not buying the advanced product earlier.

At the moment, we have about 30,000 users. These users are mainly IT operations users, but there is a group of senior execs who also receive notifications. So, we've got senior execs on the business and IT side and the IT support community who use the system on a regular basis or on a daily basis.

I would definitely rate them a nine out of ten.

Positive

A lot of data needs to be fed into xMatters to make it work. For it to be successful, there is a lot of reference data that needs to be configured within the platform to enable it to communicate with the right people. We've used xMatters for a number of years, and there is a lot of reference data, such as users' contact details, groups, and systems, that xMatters needs for integration with to receive alerts.

We looked at the Everbridge solution a few years ago, and it was no way near as intuitive as the xMatters solution. Now, Everbridge has bought xMatters.

xMatters workflows haven't helped us to address issues proactively. We have use cases for which we build workflows, but they're not addressing issues proactively. It's normally in a response to an issue that we've seen or an enhancement that someone suggested that we should follow up on. Most of the enhancements that we do nowadays come from our user community. They are requested by our user community, and we can then use the xMatters workflow managers to build the solution.

I am not sure if xMatters' on-call schedules and streamlined escalations have helped to reduce SEV-1 incidents in our organization, but it has definitely enabled us to get messages to the right people sooner. The fact that we can send some of the lower-level alerts to the right people and they have improved response options means that they may have prevented further SEV-1s up the chain by fixing issues before they've become major problems.

We have not yet incorporated xMatters into our application delivery workflows, but we are looking into utilizing it. We're currently onboarding ServiceNow, and we will be looking at how we can improve the escalation and visibility of instances by using the integration capabilities between ServiceNow and xMatters.

I would rate this solution an eight out of ten.

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

My team manages the xMatters platform for our company. We're not just end-users of the platform. We configure and manage the platform for our company.
So, I'm probably a superuser.

I wasn't around when they started the implementation process, but I know what they basically needed was real-time alerts. So, if somebody were to create a high-priority incident and we had something that was production-down, we needed to alert the appropriate people in order to get that resolved. If I remember correctly, they didn't have anything before xMatters, or the solution they did have was very flaky and didn't process as xMatters would. So, the use case for it was to get less downtime.

There is also the business continuity side, such as knowing what locations people are in, where xMatters is used a lot more than the IT side. For example, if there is an active shooter in a single location, you can use the business continuity side of xMatters to send out an alert to all of the employees asking them to take cover, get out, and do something, or if a building blows up or is on fire, you can send out a message through the business continuity to say that nobody comes to work.

We definitely saved money because of time to react and minimized downtime. Efficiencies have gone up because less downtime makes for better efficiencies. Auditing, reporting, and logging are helpful when an event kicks off. If everything is configured properly, when an event kicks off, we have a record. For example, we can say, "This was supposed to be sent out at this time on this date. Here you go." We also have a record of whether somebody reacted to it or not.  xMatters not only sends out an event alert; it also tells you, "I'm trying to message this person after however many minutes, and their shift is set up. This person did not respond. We're going to go to the next one." So, the escalation process for this is on point.

We have a couple of integrations. ServiceNow is one. Its integration isn't seamless, but it is as close as you could probably get in the IT world. We also use a Lenel integration, which is like a hard access deal. It is home-built though, and it is almost like it shouldn't be there.

When I first started on the team, we had an ITSM tool called EasyVista. The integration that we used from EasyVista to xMatters was a completely customized integration. We customized the xMatters side of it and the EasyVista side of it to super tailor everything down to a T, and then, a few years ago, we moved over to ServiceNow, and we decided we didn't want to do so much customization within either tool. So, we went more out-of-the-box, which produced some issues and problems. They were not necessarily from xMatters themselves. They were more or less related to the process change where we had to tell the users that this is how it's going to be going forward. It won't be the same, and we understand it won't be the same, but to enable better upgrades and less vigorous testing, we want to use more of an out-of-the-box integration. It was great that xMatters already had a pre-built integration to ServiceNow. They're a ServiceNow partner. So, basically, you install the plugin and set up the plugin for your instances, URLs, endpoints, and other things, and then you're good to go. You don't have to change form data. You don't have to change values and variables. It was a big positive.

I personally don't use its logs. Our company uses the log part. So, if we have an auditable incident or issue, or something comes up that needs to be traced and audited, they use the logs, and they use the reports and everything else that xMatters gathers during an event alert. We'll use all that information even for legal purposes. I'm sure that's happened in the past.

We use xMatters’ REST API. It is excellent for customizing processes and information.

It has 100% helped us to automate our incident notification process. Before this, we didn't have any escalation process other than a manual call to the next person.

The incident notification process has definitely affected our business in a positive way. We can now set up escalations, and we can set an alert to contact xMatters and trigger certain form data. So, when there is a high-priority event, xMatters takes over the notifications and then escalations.

For us, their biggest feature is event alerting and the retention of those events. This way, if something goes wrong, we can provide a report of everything that was sent out and everything that was captured.

In terms of intuitiveness and flexibility of xMatters when it comes to customizing on-call schedules, rotations, and escalations, for me, as an IT professional, setting it up isn't that big of a deal, but I understand that some people struggle with it because when you get wrapped up into it. You can get lost. It's not super complex, but it's complicated enough to the point where you can say that you should have done it another way. The shift part can be confusing for some people. In that respect, one of the shortcomings my team has found is when we have to add another person, such as a new hire, to xMatters, we can't add them to a group within xMatters without having to put them on a shift. If we put them in a group, they have to be on-call. We can create their account, and then they're just out there in limbo until their team says, "You have to be on this shift." One piece of feedback for xMatters is to figure out how to have manageable groups so that they're contactable from xMatters. They do not necessarily have to be on a shift right from the start or at all for that matter. That would be the number one thing. Our boss says all the time, "Well, you got to create them and add them to the group," but we can't exactly add them to a group because we're not on that team. We don't know if they should be on-call, and if they should, whether the shift they have installed is during the business day, after-hours, or a weekend. Everybody has got their own shift created, and we would not know what shift to put them in. We could start asking that on new user creations, but when we're doing new hires, it's more or less just common practice to create all their accounts. We can't create an X manager's account for a few things. That's not how we have it set up. We could change all of that, but that's where there is a gap. 

One of the shortcomings or room for improvement is that their mobile application seems subpar. They could really revamp it and make it function a lot better. There have been too many times when it timed out, and you don't even get to know it. You could go a month or two months without getting an on-call alert, and then, you get one, but it is never alerted in the application. So, if you don't have your cellphone number set up, you'll never get notified, and then you go back to the app to find out that it has automatically logged you out, and you can't get back in. The mobile applications, for both iOS and Android, should definitely be revamped.

I have been using this solution since 2017.

It is very stable. We've only ever had two issues with xMatters as a vendor, and when we did have those issues, they were on top of it and fixed those issues immediately.

Its scalability is excellent. It is very scalable.

Their support has been fantastic. We have regular meetings with account managers and even tech managers on that side. We might be one of their larger clients. So, every time they have a major release, they set up meetings with us, and we can go through the new features they want to introduce and the stuff that has been maturing lately. It is a very good relationship. I would rate their support a nine out of ten. There is nothing against them, but there is always room for improvement somewhere.

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

I wasn't around when they started the implementation process. In terms of maintenance, they handle most of their upgrades. I like that if they have a major release, we're getting put on that major release. We aren't 10 releases behind because they manage all of the instances themselves, which is great, and that's one thing off my team's back.

I know roughly what we pay per year. For what we use it for and what its purpose is, it is very valuable.

Our workflows are built in ServiceNow for incident pieces. In xMatters, they are built for just the form data. So, we have built workflows, but that's just our particular instance. We primarily use workflows on xMatters for form data. On the workflows on our ServiceNow side, we interject the REST or an email integration to xMatters. During the workflow of ServiceNow, based on the type of event, we trigger xMatters and move on to the next piece of that workflow.

xMatters' on-call schedules and streamlined escalations must have helped to reduce SEV 1 incidents in our organization, but I can't give the numbers. Now, people are getting notified, and we have records of all the high-priority and critical-priority things. So, they've done a little tech debt resurgence there and tried to minimize all of that. Nobody gets woken up at 2:00, 3:00, 4:00, or 5:00 in the morning.

Our incorporation of xMatters into our application delivery workflows is minimal. We do use Dynatrace alerts to message xMatters. Other than that, it is basically for when you have configured databases that go down or things like that. It is all reactive. We don't have to set up anything proactive.

It hasn't helped to increase the application release rate. It is probably at a stagnant level. It is a resource constraint thing for most of the teams around here, and it has nothing to do with the tool's shortcomings. It is all resource-based.

I would rate this solution a nine out of ten.

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.

We use xMatters for critical incident management. It's used when there's a true IT emergency, and we keep on-call schedules in the tool for various support teams. When the xMatters service reports a P1 critical incident, a workflow goes to an on-call team to evaluate the request. If the incident management team determines this is a critical incident, they will use xMatters. We have a template that notifies the necessary teams of an issue with the system and tells them to join a bridge call.

We only use xMatters' bridge capabilities for a disaster recovery option when Microsoft Teams is not available. Then, we send out a notification to the appropriate teams, asking them to join a troubleshooting bridge. Those teams are responsible for creating and managing on-call schedules in xMatters, so we're sending notifications to people who are up and working, not getting people out of bed.

We can instantly escalate a critical incident. Before we implemented xMatters, escalation for an urgent issue could take over an hour, but now we can evaluate the incident in less than five minutes. We can have a critical incident bridge spun up within 10 minutes, and all of the necessary teams join within 15 minutes, so it's cut our response time by 75%.

With xMatters, we can immediately notify the correct teams of a critical incident and ask them to join the bridge. Previously, it was like a telephone chain to get the appropriate people involved, but xMatters has automated that, drastically improving the response time. 

That automation is the critical aspect of xMatters. Without those workflows, then we would just have a system that maintains an on-call schedule in Excel. xMatters provides the notification workflow and ensures you're notifying the right person at the right time. That's mainly how we're using xMatters right now. We haven't felt the need to use coding to expand the functionality of the workflows. They're pretty robust.

Using xMatters' workflows reduces false positives. A high-level team evaluates an incident and determines if it's critical or not. That has reduced the number of false positives by about 60%. We didn't have that workflow so that anyone could call a critical incident. Then once we got people on the bridge, we would realize that it wasn't a critical incident. We couldn't vet the request. With xMatters, we have fewer false positives, so instead of having 25 P1s a month, we're now down to seven. But xMatters itself won't prevent our network from going down or an application from failing. That's not what xMatters does.

xMatters is easy and flexible. It gets complex when you have to go in and set up specific time zones and countries for the follow-the-sun-model to work. That takes some maintenance to ensure that we have all of the appropriate time zones for our users reflected in the model. But that's an administrative function for a team leader to set up. It's easy for them to create schedules or add people to different schedules. You can set the escalation path so that if one person doesn't respond, it will wait a certain amount of time and go to the next person. Or even go to more than one person at a time. There's a great amount of flexibility to customize, but it's also effortless to set up.

The on-call schedules and the escalation paths are straightforward to set up and maintain. The logs provide a level of detail that allows us to recreate exactly what happened in the communications. That's come in handy a couple of times. For example, sometimes people will say that they never received a notification, so we'll look at the logs and see whether it was delivered to their device or not. 

I would like to see some user templates. There are roles like administrator and user, but it would be nice if an administrator could create a user template that restricts what people assigned to that role can do. For example, in a standard user role, each user has a profile where they can update their mobile number or their name. It also allows them to choose whether or not they participate in specific workflows or want to receive phone calls versus SMS messages. We need the option to restrict that. 

When xMatters sends off a workflow, they should receive an email, phone call, and text, but they'll only get the email if they've opted out of the text and phone on their profile. Then we end up waiting on a bridge for someone from that team to join and realize that they haven't received the alert. They just got an email. We're using xMatters as our emergency alert system. If we just wanted to send out an email and wait for people to join, we would use Outlook. Unfortunately, we have no way to prevent people from choosing not to receive that level of notification. We would really like to be able to do that.

My company acquired the license for xMatters about five years ago. I only joined the company a year and a half ago, but the solution was purchased a while back. They purchased the license but didn't start implementing it until roughly two years ago.

We have never had an issue with xMatters. It's never gone down or been unavailable. We've never had something fail. It's highly stable.

I believe that xMatters is highly scalable. Senior management sees the value of this tool, and we are looking to expand our user base. We have about 200 users right now, and we're getting requests every day to add more teams to it. There is an executive group, which includes our CIO and all of her direct subordinates, and we have a workflow if we need to notify executive leadership down to first-level technicians. Those are the people you want to get on a call with first to evaluate an issue. It's used at all levels of the organization.

I rate xMatters support 10 out of 10. I've never contacted xMatters support, but I think it's good. I've had regular calls with our account manager, and we have a support engineer assigned to us. We've sent them email questions, and they answer quickly. And then they also do live webinars for new features. 

Positive

Before implementing xMatters, the administrators and supervisors went through training on the company site. We watched some training tutorials and followed along. After that, it was simple to start creating groups and workflows around that. The setup itself was intuitive and straightforward, but the training documents and the videos are excellent. They're much better than what you would typically find, I think.

We've seen a considerable return from xMatters, particularly its ability to evaluate critical incidents before everybody gets on a bridge. That's a significant dollar savings because we're not asking people to stop what they're doing and join a bridge, then it turns out to be a false alarm. I think there are quite a few features available, but we're not using a majority of them.

There's a significant difference between a full license, which allows people to respond to messages or acknowledge a message, versus a more scaled-down license, which only allows people to see the notification. The full license is significantly more expensive, so we need to evaluate whether new users need it when onboarding them into the system. It does require some active license management to make sure that people have the correct licenses, and we're not handing out full licenses to somebody who will never need to respond to messages or participate in an active workflow where they have a step they need to complete.

I rate xMatters 10 out of 10. We learned that we have to restrict who can use it when we're setting it up. This is another example where it would be nice to create a user template type. We found that when we're creating workflows, a user will believe that they can call a critical incident if they can see it. They'll do that without going through the necessary steps or evaluation. We had to do some work restricting who can see what workflow.

The use case is mostly getting people on a call as fast as possible, especially since we heavily use ServiceNow. In one account, it has really been more to reduce the time to resolve issues. This has usually been very difficult since they don't have a paging system. They would start asking the command center to call this person or that person, then multiple people were being called, joining a bridge, sending emails to a distribution list, and searching names in the directory. 

When I came to this account, they had already been using it. It was really more about protecting the workflows when I came in. 

It reduces the mean time to restore a service. Before, it would probably take an hour to get everybody settled down. With the integrations right now, if somebody flags a major incident, then everyone is on a call in the next 15 minutes.

We usually only use xMatters for major incidents and when multiple teams are needed. We don't really use them for anything else. When there is a major incident, you need probably three to five teams on a bridge to resolve an issue. If you are looking for the right person and finding out who is on shift, then you have already wasted an hour, at least, trying to bring in people. So, if our service level agreement for priority one is two hours, then imagine wasting an hour trying to bring everybody because that means you have one hour remaining to fix an issue. So, it definitely did help. Our time did go down for priority one cases. Our average went from more than four to six hours down to about two to three hours.

xMatters has helped to automate our incident notification process. Because, if there is an integration where they flag a ticket, that is a major incident. It will then be automatically assigned to our incident managers. When ServiceNow assigns a ticket to us, the integration will automatically page our incident managers, and say, "Somebody said that there is a major incident." That has definitely helped because we are also not running 24/7 operations. So, it kind of helped ensure that somebody was looking at it at any given point of time. However, other teams don't really use it for notifications on their day-to day-operations. The only notification that they get from xMatters is when it pages them to ask them about joining a bridge for a major incident.

The most valuable feature is the ability to page people and get them on a call as fast as possible. 

The integrations with other tools, such as ServiceNow and Microsoft Teams, really help a lot to reduce the steps needed by incident managers to do their job.

On-call schedules are very easy and user-friendly; they are not difficult to use. I have taught a couple of people how to do them, and they were able to follow quickly. Its on-call schedule and interface are probably a lot friendlier than ServiceNow. We don't really use on-call schedules a lot, except for incident managers. Everybody else is 24/7. 

When I integrated xMatters and ServiceNow, I now know which messages were sent just by looking at the logs in a ticket. I know who accepted or declined the messages. So, these logs are really helpful.

It took me awhile to get used to whatever was available in the interface. The interface from two years ago was a bit more confusing when looking at where you should go. Once I got the hang of it and found where I needed to go, it was easier than I thought. The only limitations have been when I was looking for a specific integration that would allow me to integrate with ServiceNow and Microsoft Teams without going through multiple channels, e.g., just click a button in ServiceNow and the rest will be done. That is the part where I really needed help. However, everything else is easy and straightforward, such as configuring what the alarms would look like and configuring how to send a message without coding.

I haven't had the chance to play around with the new workflows. So, when I attended their roadshows and a couple of meetings about it, I didn't really pick it up that quickly. It sounded a bit more complicated my level of skill, since I am not a developer. Therefore, I still needed to sit down and understand how it works. Right now, we really don't have a business case to use it yet. 

I started using xMatters somewhere around 2017 or 2018 with my previous account. I am a consultant for this company, and we are a third-party managed service. The company outsources their services to us. Before my current project, I was with another account where we also implemented xMatters.

I have not had any complaints since we have been using this. I haven't heard any really bad feedback. If we did receive bad feedback, it is really more about people complaining that xMatters keeps calling them, but that is the way I configured it. If there is a major incident, until you pick up, then it will keep calling you. So, if they are annoyed with the amount of time it calls them, then that is not xMatters' problem. 

I have only heard a couple of complaints about not receiving alarms. That was once or twice in the two years that I have been using it. They didn't get a notification once or twice. Unfortunately, I wasn't able to get in touch with xMatters at that time, but it wasn't really a big deal so I just let it slip away.

The most maintenance, which I have been doing, has been adding and removing users. This could be solved if they had enough licenses, so when we add them to ServiceNow, they would automatically be assigned an xMatters license.

Adding users is five minutes per user, but we don't really have a lot of users in the environment. We have 200-something from time to time. We only give licenses to team leads, managers, directors, vice presidents, and C-level executives. It is not like we have a lot of users who come in and go all the time. Once in a while, they tell me somebody has left and ask me to remove their license. That does not take a lot of time.

The support has been excellent. They are very knowledgeable and approachable. I work with a person who was kind enough to help me write the code for the requirements that we were looking for. That really helped us a lot and took our xMatters integration to the next level.

Positive

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

I had the privilege of at least playing around with the tool before I joined this account. With my previous account, when they started using it, I knew the very basics of what it was and what it was for. However, being the admin and configuring everything, that was a first. For a while, I had to really dig deep into using the dev environment and looking at the fields, e.g., what they are. 

I have a knack for figuring things out myself, though It took awhile, but I attended a couple of training courses and sessions also with xMatters last year. That really helped a lot. There were things that I didn't realize were there, and those were the things that helped make it what it is today.

Integrating it with ServiceNow was a bit more difficult than I thought since I personally don't have a developer background. So, I relied on mostly common sense to figure it out, but my common sense could only take me up to a certain point. I then had to reach out to somebody from xMatters to help me, and he did all the coding for us. 

I am not really privy to how much my client is paying for this service. They just tell me the number of licenses that they have. Every time that I say, "I need extra licenses to make sure that all Level 1 and 2s have their own xMatters account," they keep telling me that it is too expensive. If the only purpose is to call people, it doesn't justify the cost of paying more than the number of licenses that they already have. 

This limits my ability to implement other things that I had hoped could have been implemented, like the notifications. For example, I could have used notifications to inform people that there is a P1 or P2 assigned to them. However, because of the limitations and licenses, we could not. 

We explored the ability of ServiceNow to page people. Though, we didn't really have an opportunity to deep dive into that because somebody decided to use xMatters instead.

The solution is excellent. I would rate xMatters as nine (out of 10). The workflow configuration is not really friendly for people, like me, who are not developers. Everything else is great.

If you really want to reduce your mean time for restoring a service during a major incident, xMatters would definitely be the right tool. I haven't encountered another tool, not even ServiceNow, that starts calling people during a major incident. For this purpose, it is definitely very helpful. 

At the end of the day, our goal is to keep environments 99.9% available to customers. The only way to achieve that is to reduce the mean time to restore a service whenever there is a major incident. 

Definitely give xMatters a shot and some time. It can look a bit complicated, but you can attend their roadshows and free training, offered during the pandemic. That helped us a lot, because there are things in the tool that you will find out were there that you never thought were there in the first place.