What is your primary xMatters use case?
We primarily use xMatters 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.
How has xMatters helped your organization?
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-ofthe-box Cherwell 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 be: 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.
What is the most valuable about xMatters?
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. The IT department within our company 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.
How long have you used xMatters?
I‘ve been using xMatters for about five years.
What do you think about the stability of xMatters?
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.
What do you think about the scalability of xMatters?
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.”
How are customer service and support?
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.
Which solution did you use previously and why did you switch?
We previously used a competitor. We switched because they 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.
How was the initial setup?
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.”
What was your ROI?
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.
Which other solutions did you evaluate?
We evaluated competitors at the time of selection, but we haven’t evaluated any product recently. 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.
What other advice do you have?
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 as 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.
This case study originated from Peer Spot. You can find the original review here.