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.

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.

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.

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

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

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.

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.

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 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 have three instances of xMatters. One is for customer support, one is for our internal IT, and the third, that we recently procured, is the SaaS version.

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

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.

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.

We have two primary use cases. One is alert notification and escalation. The other is major incident notification.

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.

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.

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.

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.

• Major Incident Management
• Hosting conference bridge calls.
• Managing IT Support on-call schedules.

On-Demand IT Support group paging for critical incidents and paging from ServiceNow integration for incident management.

We use this tool for our primary IT and Emergency Management notification tool. We use it to send incident notifications from ServiceNow. Our datacenter command center uses xMatters to send out outage and emergency notifications. 

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

We use xMatters for alarming infrastructure outages and failures of batch jobs (post-processing).

The tool itself works well, but when you try to apply real world use cases against it, it comes down a rating scale quite significantly (hence why it is a five out of 10). The feedback we get from our team managers to modify their schedules, it is very complex, hard to use, hard to navigate, and reschedule things. Therefore, my team ends up having to do this. From a scheduling standpoint, this is actually causing more work than what we had with Excel spreadsheets.

On-call notifications.