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.

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

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.

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.

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.

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.

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.

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.

The end user accesses xMatters logs. As the support team of xMatters, we use their logs for troubleshooting, e.g., to see when an event is triggered, the process of that event, who was notified, and whether the delivery of the message was successful or not. If we cannot resolve a user's inquiry, then we will always work with xMatters' support engineering team to conduct further analysis.

Based on my support experience, it seems like our end users can integrate xMatters into event notifications and other applications successfully. Occasionally, we get support inquiries, essentially trying to understand how a particular functionality will work. If the functionality failed to work as expected, then we have always been able to get solutions from xMatters' support engineering team.

Here and there, we have made use of coding to expand the flexibility or functionality of xMatters workflows. I have created some custom workflow setups. For example, as part of account management, we do a scheduled process that will notify all the inactive users by sending out a notification via xMatters. It will ask them if they still need their account or not. Overall, the workflow is very simple, and the one that I built is not complex.

xMatters supports our usage and what our end users are trying to accomplish. As long as all our end users are supported on their operations, then as a support team, we are good with the product. 

Previously, we used to do everything manually. We used to call our on-call resources manually. If we wanted to inform someone, we used to use Outlook email. Now, it is much easier because we're using the subscriptions based on location and affected services, which is amazing.

We have the Inform with xMatters feature and the Engage with xMatters feature. We are also using the major incident feature where it sends SMS and text messages. We use it only to communicate with the IT leadership, and it is great. Previously, we used to send text messages manually using our cell phones. I'm not in the US. I live in Panama. So, when I send a message, it normally gets a different number. So, no one knew how to add my number or whatever number they get from my cell phone to their safe contact list. Now, we have a specific phone number that doesn't change. So, they know who is calling, why they are calling, or why they are getting messages. That's very good. The customization of those text messages from the web service is also great.

It has helped us to build workflows that meet our needs. The ServiceNow workflow is very good. The Major Incident Best Practices workflow is another one. For our next application, there would be a new workflow that I need to create. We are also using the Emergency Change Management workflow, but the most important thing for us is major incident management. We use it for all Sev-1 and Sev-2 incidents and almost everything related to major incidents.

xMatters workflows helped us to address issues proactively. From the Major Incident Best Practices workflow, I created a workflow directly to Teams to post a notification on our Teams channel so that everyone who isn't subscribed on xMatters can see the notification that we're sending out. It helps a lot as well. I did it myself, and it was pretty easy.

xMatters provides targeted, content-rich notifications to reduce response times in our organizations. It has reduced the response time by at least 50%. Previously, we used to call people manually. 

xMatters on-call schedules and streamlined escalations have helped us to reduce Sev-1 incidents in our organization. We can contact any person. There is a 20% to 25% improvement because Sev-1 incidents are more related to the vendor. They are not internal issues.

We have integrated it with Slack to see who is on-call. We do a query on Slack, and it just brings the information back from there. The integration was pretty easy. We just had to install the app, and after that, we got it going. 

It brought efficiency in terms of how quickly we resolve matters and how quickly we can get in touch with the person who is actually on-call. It has definitely helped us with efficiency in that. 

It has helped us in building workflows that meet our needs. We have such a wide network of teams. We are all across the globe, and to be able to interact with people at a short notice and be able to schedule where we know what's happening has been really good.

Its targeted, content-rich notifications have helped to reduce response times in our organization. We are able to set up notifications through our phones and through the system. So, we are notified of things as they come.

It saves a significant amount of time because I get the notification immediately on my phone when things are not working, and I'm able to quickly say "I'm on it," or "I'm resolving it." It is really helpful to have that integration. So, there is definitely a significant amount of time savings.

We have integrated xMatters with other tools such as Workplace, Power Automate, and Microsoft Teams. It can be used to interact with other webhook endpoint URLs, as well. The Flow Designer is what we have built most of our integrations from, and once you know how to use it, creating integrations is very clear and obvious. When you are getting started, however, it can be a bit daunting and is not as clear as it could be.

There are plenty of tools that xMatters integrates with and they are always adding to that list. Also, if there isn't a pre-made integration available for a tool then you can customize and create your own. This is something that is very helpful.

xMatters has helped to automate our incident notification process, and they have provided us support with doing so. One example had to do with a major incident process that we have set up. Previously, it was a two-step process where our major incident management team would engage stakeholders to bring them onto a conference bridge. It was a two-step process to ensure that the major incident manager was available for the bridge and there wasn't an issue that the major incident manager was facing. With the help of our customer success manager at xMatters, that process was streamlined in such a way that the same level of customer security and two-step verification could still take place, but it was done with less effort needed on the major incident manager side. It still has the same output and meets the same criteria, but with less effort needed from the major incident managers to do it.

The workflows in xMatters have helped us to address issues proactively from the perspective of stakeholder management. It ensures that the right people are aware and advised of issues in the company. It also helps with managing our licenses, which has been very helpful.

Another benefit to using xMatters is the fact that it's always available, regardless of device. If we were to have an issue that meant I could not use my laptop, I can then go and use the app on my phone, or another approved device to be able to access xMatters. That's really helpful for me. It's not just the availability but also that it's usable on so many different platforms. I'm not restricted. This has come in handy in the past when I haven't been able to use my laptop to send out communication and I've had to use an iPad or a tablet.

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.

xMatters helped to automate our incident notification process. We generate incident tickets right from our alerts. That ability is excellent because we're able to respond immediately and indicate that someone has taken ownership of the alert.

We also use the coding to expand the functionality of xMatters workflows so that we can ingest information from a security solution. That will then generate an incident in Micro Focus Service Manager.

In addition, we have seen reduced response times, and the streamlined escalations have helped to reduce priority-one incidents in our organization.

At one time I was working in our global network operations center. We had a few difficulties in reaching out to the on-call resource. I would call someone only for that person to say, "Okay, I'm not on-call this week. You should call this person," and that person's number was unreachable. Then I would have to call the first person again and he would say, "Okay, now call this person," and he might also not be the right person. It was a time-consuming process and there was a delay in dealing with the service disruption. Implementing xMatters has helped us to identify who the on-call person is, and the built-in escalation really helps.

Managers can also get an idea of which on-call resources acknowledged an alert, and whether it was escalated to the next level or the third level.

Also, the targeted, content-rich notifications have helped to reduce response times, although we haven't measured by how much.

We have only integrated our Sev-1 incidences. Once a Sev-1 is generated, an xMatters alert is automatically triggered and the on-call person acknowledges the event. With that acknowledegment, the incident's status is changed to "in progress." As a result, responses to incidents are at 100 percent. We also have a checkpoint. When there is an event, a NOC engineer reaches out, every 15 minutes, to the person who has acknowledged the event, about whether there is a service disruption or not. With the quick responses to alerts, we have time to figure out what our outage notification or disruption message will be to our end customers. All of this definitely helps us to reduce the communication involved, as well as expedite the restoration of service. 

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.

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.

In the past, when there was a major incident notification, which is an outage for one of our products, we had one tool that we would use for email notification to our internal stakeholders, another tool for a voice blast going out to their phones, and then another tool for a conference bridge. All of those needed to be kicked off individually and managed individually by our enterprise operations center. It was very difficult to manually maintain call lists - who was on call when - and up-to-date contact information. So, when there was an outage, we didn't have the right people on the bridge, it took forever to get people on the bridge, it took us a long time to notify people there was an issue.

By using this tool, it's a one-stop shop. Through one tool, we're able to generate email notifications, voice notifications, mobile push notifications, Slack channel notifications, all managed from one place, simple and easy to use. People are able to join the conference bridge directly from the phone call by pressing one button instead of having to dial into a bridge and remember a conference code.

Everyone's contact information is up to date, people are able to go in and update their contact information and even set things like when they're going to be on vacation and who their backup is. 

It has dramatically cut the amount of time that it takes to get people assembled during a major incident.

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.

We're able to communicate better with specific groups or offices. We didn't have that capability or granularity before. It has helped in that regard.

Automation of our incident notification process has increased our capability to respond. We can not only alert a whole group of people. We can also configure escalations so that one person is notified, and then it continues up the escalation if it is not responded to.

It has helped us to build workflows that meet our needs. It is important for us because it just helps create additional efficiencies. If we can configure workflows, that typically helps us be more efficient when there is an issue. xMatters workflows have helped us to address issues proactively.

The targeted and content-rich notifications have helped to reduce response times in our organization, but I don't have the metrics.

Its on-call schedules and streamlined escalations have helped to reduce Sev-1 incidents in our organization.

We no longer have to manage the notification process manually.

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

We have reduced the time it takes to resolve major incidents through xMatters’s conference bridge management solution. Instead of a service desk agent sending an email or manually calling multiple resources to join a bridge, xMatters directly calls the appropriate resources simultaneously. In addition to streamlining the conference bridge process, xMatters fully logs all notifications to show who was contacted, how they were notified (phone call, text message, email, and push), and if they responded. This helped change behavior across the organization to improve accountability.

By adding the ServiceNow integration, we have been able to page support groups for critical incidents and move scheduling from ServiceNow into xMatters, offering more control to our support groups. 

The two-way integration between ServiceNow and xMatters also allows us to assign tickets to support personnel faster and respond to incidents faster.

The automation of the tool and the way it integrates with ServiceNow has improved out IT operations. Also, users can manage their own devices, which has saved our datacenter time because they do not have to manage on-call devices or rotations anymore. 

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.

• xMatters made it easier to implement our roster of people who receive alarms using the REST API. 
• The cloud solution reduces alarming to the core, which means no need to provision your server, which is great.

It has not improved our organization.

This has made it much easier to send notifications to a group or individual, as you just need to know the name and the message to send. xMatters handles the communication methods (phone numbers, preference of text, email, phone call, etc.).