What is your primary use case for xMatters ?

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.

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.

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.

It is mostly used to schedule our on-call system to support our customers. We use it a lot to schedule people, put in absences, etc. We also use it to see the other teams that we can contact.

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 have two instances of xMatters. One is for IT alerting, and one is for business continuation. We leverage our IT instance to notify different IT groups, such as system administrators or web developers, and then escalate an issue to a specific group. We utilize it for disaster recovery to be able to send out messages to either the entire company or a more granular group of individuals, such as a specific location or specific departments.

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 use it as an integration point with our monitoring solution, which is Micro Focus Operations Bridge Manager. We also have an integration point with Micro Focus Service Manager.

We use xMatters to handle system alerts. Generally, we use xMatters as an automated process in particular systems. For example, if the source detected an issue, it will use xMatters to alert the team member to resolve that issue. xMatters is utilized as part of our system monitoring and alerting. From the support team side, my focus is more account management, which is my primary task.

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

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 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 use it mostly for major incidents. To contact, we use the group on-call schedule feature. We use it to communicate and notify our IT stakeholders and executives. We are about to use it for incident alerting on applications. We will first start using it for one application, and then we will see how it goes.

Our primary use case for xMatters is instant communications and stakeholder engagement. We send out instant communications whenever we have a major incident within the company. In addition to situations like this, we use xMatters when we have other high-priority matters and we need to engage the right people as quickly as possible.

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.

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