xMatters Reviews

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

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

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

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

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

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

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

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

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

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

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

3- Groups creation and resource mapping to the appropriate groups

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

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

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

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

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

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

1- Duplicating the Groups

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

3- Bulk update of groups

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

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

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

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

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

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

We did not use a different solution previously.

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

We did not evaluate other options. 

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

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

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

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

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

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

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

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

The support groups themselves are the most useful part.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

We're not using it for the rota aspect. We specifically use it to send communication out to the business and also to arrange calls at the bridge where people can join the bridge. We have integrated it with other applications that we use heavily, such as Workplace by Facebook and Slack. Once we've sent out our communications via xMatters, it sends an email and text message to users or the intended people who are supposed to receive the message. That message is also posted on Slack and Workplace.

It is an efficient way to deliver communication to a large number of users across a number of different applications. It has helped in getting the right information out to the right people on time. We are able to ensure that they all received the information in a timely manner. 

It is helpful for us in getting the communication out to multiple users on different platforms in a timely manner. It brings ease of use in terms of us inputting information only into one system, as opposed to three or four different locations, and that includes being able to contact people. If we need to have everyone on a call, it is easy to open a bridge, and the relevant people would receive a phone call who can join automatically through the bridge.

Workflows and messaging are most valuable. Workflows are very useful. They are important for consolidating information or stopping duplication from happening. We put all the information into xMatters and then the workflow will push the same information in the correct format directly through to other applications that our end users frequently use, such as Slack, email, and Workplace. 

The other main part that we use is messaging. We use it for our major incident communications and our change freeze communications. We also run our testing through there. So, when we're doing test incident communications, we run those as well through xMatters.

We have integrated it with other tools such as Slack and Workplace. It is straightforward to integrate, but the first couple of times, you do need a level of understanding in terms of what you're doing. However, it is not difficult to get that information. There is lots of information held on xMatters knowledge base itself, which is very useful. There is always someone else who has implemented the solution that you are looking for. You can pretty much find anything you need within xMatters. There have only been a couple of instances where we haven't been able to find a solution. In such cases, we contact our account manager, who is very helpful. They help us with any particular difficulty that we're having, but once you are familiar with the workflow builder and how it works, it is very easy and straightforward to create new workflows and integrations.

One of the main reasons why we don't use xMatters for monitoring and alerting is that it doesn't use the rota to call the person who's on-call. It doesn't look up the rota to find out who's on-call and then contacts that person directly. I am not sure if this has changed now, but the last time we checked, this functionality wasn't there. This is one of the main improvements. We're happy with the rest of it.

I've been here for three years now, and it has been used for longer than that.

Its stability is excellent. I've never had a situation where xMatters has gone down at all. I never look at it as a tool about which I'm concerned that it may not work. I'm always able to get access to it. Whenever we needed it, we were always able to get the communication out. It is very reliable.

It is definitely scalable. We have our incident communication that goes out, and we also use it for our business continuity, which is specifically set up for emergency purposes where we are able to send text messages out to the entire company. In terms of scalability, it is highly scalable. It is nice because you can tailor it to your own specific requirements even as they change. The one main thing for us would be the scheduling part of it so that if there was an incident, it contacts the right on-call person. However, our technical teams use PagerDuty for that. In our team specifically, which is the service delivery department, we use xMatters to notify of major incidents.

On our side, it is my team, which is the service delivery team. There are four of us, and then there is the services team as well. So, the services team uses xMatters for business continuity, which is to notify people. For example, in a fire emergency, everyone has to leave the building. So, there are two specific teams that use xMatters: the services team and the service delivery team.

I've never had a problem with xMatters, per se. The only thing for which we contact xMatters is if we're trying to set something up specifically that we cannot find through a knowledge base article. The response is great, and we always get to where we need to be. We always end up implementing the solution that we set out, so we always achieve what we wanted to. So, they provide great support. On a scale of one to 10, I would definitely rate them a 10.

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

I wasn't involved with setting it up from scratch. I've set up new workflows for which you obviously need your users and groups and then you create your workflow with whoever you want to send it to. It's relatively easy. As long as you follow the initial user guide and you have a clear understanding of what you're trying to achieve, you can set up some of the basic functionality easily in order to get going by yourself. The rest is all available in xMatters' knowledge base.

It doesn't require any maintenance. There isn't any maintenance on our side. It's all cloud-based, and we just log in and carry on using it. xMatters does regular updates, and they notify us when there is an update, which is often quite useful. That's it.

I don't make the decisions on the cost aspect. We haven't had any complaints. I think it has a reasonable price. 

My advice would be to have an idea in mind of what exactly you are looking for. You should look at the different ways that other businesses use incident communications because a lot of companies may not think of certain solutions that others are using. So, rather than evaluating the product based on what it can do, it's always useful to see how other businesses are already using it. That's most helpful in my opinion.

Its logging capability is very straightforward to use. It is not difficult, and it is very informative. From the information contained within the logs, it is not difficult to find out where the failure occurred. We don't use xMatters logs as part of our operations. We only use logs to find out if we've implemented something that doesn't work, or when something breaks and we're trying to figure out where exactly it has gone wrong. They come in handy when we are trying to figure out where something has gone wrong, or when specific people have run certain tests, they are used to see which messages were sent and when. So, mainly, we use logs when there is an issue in xMatters, and we need to figure out where it failed.

We don't use call scheduling and rota aspects of xMatters. We also don't use coding to expand the flexibility or functionality of xMatters workflows. We used to have to do some coding, but once there was the introduction of the workflows, it kind of eliminated that side of it, so we didn't need that any longer.

xMatters workflows haven't helped us to address issues proactively. That's because we don't use it in that way. We don't use it for monitoring. It is only for alerting but not in terms of incident management or our teams being alerted of an incident. It is only in terms of alerting staff members of an issue or an incident. So, within our setup, we don't use xMatters for monitoring.

I would rate xMatters IT Management an eight out of 10.

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

I have been using xMatters for two to three years. 

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

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

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

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

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

Positive

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

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

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

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

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

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

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

This solution integrates with the service desk tool to allow for the appropriate notification of support teams. You can set up a queue of people and you can assign their devices, their priorities, and the order in which they are called. It allows for shift work and it can all be automated once it is set up. If somebody has to be contacted then it happens automatically through the interface.

The system works by allowing for support queues, where you can define who is available and who is on-call. Then, based on ticket priority, you can define what kind of notifications take place. For example, if it is an urgent ticket or a priority-one incident, then you need to make a phone call. In contrast, if it is something minor for one individual, then it's typically going to be an email and that's the extent of it.

The automation provided not only expedited communication, and therefore the ability to address issues, but also ensured that the data used for communication is managed.

The most valuable feature is the automation because it reduces the demand on resources. It automates the escalation of a ticket if the person doesn't answer within a certain amount of it, and it passes it on to the next person. People are required to respond, for example, by pressing the one key on the phone to acknowledge the call. If it was an email then it would require a reply or similar type of acknowledgment.

Having this level of automation is a great benefit to being able to more quickly contact people. It reduces the amount of oversight required, and consequently, the amount of time to assign and get a response on a ticket.

The integration with other systems needs to be more flexible.

The interface is a little bit rigid and can be improved. For example, it tends to operate on the attribute of a record. So, if a group has a name, it tends to want the group names as opposed to, for example, the ID of a record. It creates a problem because if you rename the record then you lose all of the connections.

The data validation and verification need to be enhanced so that when data is changed, it reviews it in an automated manner and catches all of the anomalies. Otherwise, all you're doing is shifting the workload from an operational standpoint to an administrative one.

We began using xMatters IT Management in 2014.

PS, I am no longer with the firm and do not know if it is still in use.

This is a stable solution. This system runs 24 hours a day, every day of the year, and stability is not an issue.

This solution is fairly scalable. In the organization where I had this running, we were handling up to 150,000 incidents per month. There were 5,000 incidents a day and an IT staff of 1,000 people. I'm not sure if it would even be cost-effective in a smaller organization.

I would say that their support is above average, although not exceptional. It depends, in part, on who you were speaking with. However, part of the reason that we sometimes struggle with support is that we are outside of the norm for what is expected.

The initial setup was complex. The reason for this is that the interface is not as sophisticated as our needs.

The configuration is partly done in the service desk tool, where it gathers the contact information or it reads it dynamically. xMatters stores the method and the parameter for contact. As an example, if the method is to contact via email then the parameter would be the email address. If the method is a phone call then the parameter would be a phone number. You can set up other methods, too, depending on how sophisticated your environment is.

Implementing and deploying the system took six months to complete, including testing to makes sure that it worked.

The cost of this solution was less than the cost of staff required for the same job, so it is saving money.

This is a subscription-based, SaaS solution. There were some additional costs during the implementation because it was well beyond their standard configuration.

At the backend, this service is initiated internally, but the notifications and alerts are sent externally to the vendor through web service calls.

My advice for anybody who is implementing xMatters is to be sure that they have a very clear plan on how they want to process whatever communications they're doing. The tool can do almost anything but you have to come to the table with the process well-defined, before you being implementation.

I would rate this solution a seven out of ten.

To notify our employees of system events that might result in an outage on our website.

It has improved our time to respond. Prior to the use of xMatters, it might take hours or even a day to get someone involved on a problem. Now, it's down to minutes.

Probably the most important one is that it persists in attempting to contact to someone until someone is engaged on the event.

Then, of course, there's the ability to define rotations and schedules for people who would be on call to handle those events.

The ability to support custom devices. We have a lot of users who use Slack, which is another tool for communication. xMatters currently does not support Slack as a communication method. It can't send events to Slack and respond to them.

Three to five years.

We're using their cloud-based service or hosted service. We've never had any problems.

We've never had any issues with scale. It's always met our needs.

I would give them an excellent rating. They've been extremely responsive and always work an issue until it's fully resolved.

We did not have a solution prior to xMatters.

We've always used their hosted service, so we've never had to set it up. The only thing we have to do is train our users on how to use it. It's been pretty easy to do so. They've actually made many improvements over the years to make it even easier to train people.

It is worth the cost.

You need to know the number of users that are going to use it, which is usually pretty easy to calculate. It's on a per-user license.

We evaluated two other solutions. One was an internal solution that was provided by our IT department, it was a proprietary solution. Then, we also evaluated xMatters vs PagerDuty. We chose xMatters because of its cost and ease of use.

DevOps means that the person who's developing the software supports the software. When an event occurs that might result in an outage, xMatters engages people on that event so they can resolve it before there's an outage.

Certainly, it's been a very stable solution, very reliable, very flexible. It comes from a company that practices Agile development, so they're very fast to deliver new features, as well as any bug fixes, should any arise. I think the only challenges we've ever run up against is some compatibility with mobile devices and the providers they've had. Usually, that's the mobile device provider's problem, not xMatters'.

I would give it a nine out of 10, only because there are some devices that are not supported.

We no longer have to manage the notification process manually.

• The ability to notify teams and monitor those notifications in real-time.
• Time-based escalation of notifications helps us resolve issues much more quickly.

Some features that have been around a while could be refined or updated, in the same way other features of the product have been updated.

Beyond the typical grouping, xMatters has what is referred to as dynamic teams.  Dynamic teams are criteria for setting up and targeting a group of people that meet specific criteria. The good thing about this setup is that you do not have to specifically target a person, or add them to the team. If they meet the criteria that has been configured for that dynamic team, the user will automatically be added to that team, and receive the notification.

The bad thing about this setup is that you cannot alter those criteria through the typical xMatters import/export process. The attributes that create the criteria for dynamic teams can only be altered via the Web UI.  So, if you want to create a new dynamic team in a mature xMatters environment (one that is already populated with hundreds of users), and you want to add, say, 100 users to that dynamic team, you have to do it manually.

In contrast, if you want to alter a custom field, you can do so via import/export. But you can't have an unlimited number of custom fields, so in a large environment with a lot of teams, team provisioning becomes more difficult.

If custom attributes could be exposed to the import/export process, provisioning of these dynamic teams would be much easier.

Three to five years.

No issues with stability.

No issues with scalability.

Technical support at xMatters is very responsive and knowledgeable.

There were some issues with user-adoption, but those have been mitigated over time.

Licensing varies widely, depending on usage. It can be cheap or quite expensive, depending on volume and features.

Put together a comprehensive knowledge base to help your end-users get acclimated with xMatters.