Syncing with ServiceNow: How to reduce MTTR by helping people get out of their own way

IT experiences regular waves of innovation, most recently with generative AI. Meanwhile, IT’s core imperatives remain constant. Year after year, Enterprise Management Associates (EMA) research consistently ranks reducing the frequency, duration, and impact of incidents and outages as the top operational objective for IT. That goal holds true for organizations of all sizes across industries globally.

The best-case scenario is to predict and prevent outages before they happen. When directly asked, “If you could choose one thing to do really well, what would have the biggest positive impact?” 43% of IT leaders chose “proactive response to incidents before they impact users,” according to a global EMA survey.

The next best scenario is to significantly reduce MTTR,1 regardless of whether the “R” stands for “repair,” “respond,” “restore,” or “revive.” That effort begins with identifying and attacking the most significant influencers on time, the first “T” in MTTR.

Host: Andy Whiteside
Co-host: Mike Sabia
Co-host: Eddie McDonald
Co-host: Fred Reynolds

Transcript

WEBVTT

1
00:00:02.330 --> 00:00:18.219
Andy Whiteside: Hello! And welcome to Episode 39 of syncing with service. Now I'm your host, Andy Whiteside. I'm happy to be back missed a couple of weeks. I think we missed a couple of weeks. There might have been a holiday or 2 in there somewhere along the way. I appreciate you guys covering, covering this while I was going. Let me let me do the commercial, real quick

2
00:00:18.740 --> 00:00:30.480
Andy Whiteside: government. We're a service now, partner, because the world needs better and more service now, partners, and if you're a service now, user, if you're a service now, if your organization has service now.

3
00:00:30.550 --> 00:00:37.480
Andy Whiteside: there's a chance that we can help you a ton, because there's always room for improvement, and the way we come about it, the way we come at it

4
00:00:37.570 --> 00:00:51.809
Andy Whiteside: gives us the opportunity to be successful with you. Long term. Yes, we are a business, but we we don't have to. We don't have to maximize profitability at your expense in order to to be a a business. And that's kind of how we see the world.

5
00:00:52.250 --> 00:00:56.270
Andy Whiteside: I've got my experts on Fred Reynolds, who runs the practice.

6
00:00:56.340 --> 00:00:59.699
Andy Whiteside: Fred, how is it going in service now's integral world.

7
00:00:59.700 --> 00:01:27.130
Fred Reynolds: It is going wonderful. Got a lot of lot of customers. We're starting to work with a lot of customers that we've done work for that. Keep coming back and looking for more. So loving the fact that we're consulting a lot. You know, I'd say part of this is obviously out there trying to to to make our brand known. But the customers we're working with are certainly realizing the type of work and the quality. We do. So. I'm loving to see the repeat questions and and consulting questions that that lead us to have that lifelong

8
00:01:27.450 --> 00:01:28.460
Fred Reynolds: customer.

9
00:01:28.460 --> 00:01:35.670
Andy Whiteside: Client for life. I'm gonna ask you a question. Give me the honest answer. I don't know. I didn't stage it customer retention rate for your group is what.

10
00:01:36.680 --> 00:01:38.230
Fred Reynolds: 100%. So far.

11
00:01:38.440 --> 00:01:38.950
Eddie McDonald: Yeah.

12
00:01:38.950 --> 00:01:40.209
Andy Whiteside: Is it really 100%? Yeah.

13
00:01:40.210 --> 00:01:43.829
Fred Reynolds: I haven't had any customers that said they didn't like us and wanted to leave us. That's for sure.

14
00:01:43.830 --> 00:01:49.036
Andy Whiteside: Yeah, I'll I'll tell you. I I got a I got a text from a former employee last week that said

15
00:01:50.200 --> 00:02:03.600
Andy Whiteside: you know he he left on good good terms, good enough terms, but he was on a golf course somewhere, and he heard somebody talking about his integra and how much the customer loved working with us, so he thought he'd give me a text and tell me that was that was pretty nice. And honestly, I needed that on Friday, after all other stuff going on.

16
00:02:03.600 --> 00:02:04.660
Fred Reynolds: Absolutely.

17
00:02:05.140 --> 00:02:07.540
Andy Whiteside: Eddie Mcdonald, how are you?

18
00:02:07.700 --> 00:02:13.900
Eddie McDonald: I'm good, Buddy, I'm I'm thinner, richer, and better looking than I was yesterday, so it's a good day.

19
00:02:14.750 --> 00:02:16.380
Andy Whiteside: Are any of those things actually true?

20
00:02:16.380 --> 00:02:19.108
Eddie McDonald: Yeah, every one of them is true.

21
00:02:19.696 --> 00:02:21.910
Andy Whiteside: Alright. Well, Eddie's a liar, Mike, how are you.

22
00:02:23.080 --> 00:02:25.421
Mike Sabia: I am doing well. I

23
00:02:26.130 --> 00:02:34.819
Mike Sabia: My wife moved out of the office to another space in the house, so I spent the the weekend, doing a new mesh networking with my thousands of IoT devices, switching them over

24
00:02:35.190 --> 00:02:36.360
Mike Sabia: now. So, feeling productive.

25
00:02:36.360 --> 00:02:40.299
Andy Whiteside: Yours? Was that her choice? Did she move out, or yours.

26
00:02:40.758 --> 00:02:44.929
Mike Sabia: I think she initiated it, but I think it was a good move, you know.

27
00:02:44.930 --> 00:02:58.360
Fred Reynolds: I love that conversation. Mike had told me that earlier today. So I spent his weekend. And I'm like, you know, that's never been a problem, because there's no way my wife would work in the same room as me, because I talk all day. I'm loud, I get excited. I pace, and I walk through the house already.

28
00:02:58.730 --> 00:03:02.600
Mike Sabia: That was my wife's biggest complaint. You talk all day long, is what she said.

29
00:03:03.280 --> 00:03:04.240
Fred Reynolds: Consultants.

30
00:03:04.240 --> 00:03:13.499
Eddie McDonald: Lee Lee and I, my wife and I had next door offices, and it wouldn't work. We had to go on the opposite ends of the house, we could still hear each other. So yeah, I get it.

31
00:03:13.670 --> 00:03:15.779
Fred Reynolds: Well, Andy goes to another, States.

32
00:03:17.863 --> 00:03:25.699
Andy Whiteside: my wife was supposed to ride with me tomorrow to Raleigh to go see our kids who are in school there, and she said, Are you gonna be on calls all the time on the way up there? And I said, yes, she said, well, I think I won't go.

33
00:03:25.920 --> 00:03:26.470
Andy Whiteside: Oh.

34
00:03:29.289 --> 00:03:33.839
Andy Whiteside: well, guys Mike, I cut you off to make fun of you. But glad to have you.

35
00:03:33.840 --> 00:03:35.019
Mike Sabia: No, no, it's all good.

36
00:03:35.500 --> 00:03:36.520
Mike Sabia: I don't know.

37
00:03:36.520 --> 00:03:42.909
Andy Whiteside: And I'm curious about your mesh network and how you do it. And I'm even more curious around your IoT comment. But that'll have to be for a different time.

38
00:03:44.676 --> 00:04:00.070
Andy Whiteside: So, guys, you brought a blog here from August 29th of 2024, I you know. Funny. I I read that date, and I said, Well, that's last year. I think that's in the future like Oh, crap! It's already September. I literally have forgotten, and it's from Valerie O'connell.

39
00:04:00.280 --> 00:04:19.540
Andy Whiteside: So thank you, Valerie, for writing this and the the title is how to reduce M. Ttr. By helping people get out of their own way I had to go look up what Mttr. Is. I know you guys knew, and it's mean time to resolution. That's paramount. If you're working a

40
00:04:19.750 --> 00:04:33.510
Andy Whiteside: customer call center a help desk. You name it. I think that matters whether it's me complaining about my new, you know, my new top or my bronco being too windy, or you know somebody complaining they can't log in, or their logins are slow. Mike, why did you pick this one.

41
00:04:34.390 --> 00:04:44.690
Mike Sabia: I thought it was pretty apropos, and also it was recent. We always look to have blogs that are that are recently published so that we can speak to topics that may people may be interested in.

42
00:04:45.155 --> 00:04:47.230
Mike Sabia: You know. Mtdr. Of course.

43
00:04:47.550 --> 00:05:10.440
Mike Sabia: refers to mean time to resolve or repair, but it also has some other definitions depending on how you want to use it. Mean time to respond service. Now's 2 principal sla's are regarding response and resolution response would be the 1st person to assign to it, and the resolution is the the resolution of the issue. Sometimes those are both exposed to customers, sometimes only one and the other is just used internally.

44
00:05:10.720 --> 00:05:14.480
Mike Sabia: but very apropos and and pertinent topics.

45
00:05:14.710 --> 00:05:23.770
Andy Whiteside: Fred, does this acronym apply to just the Csm portion itsm. But Csm portion of service now, or just kind of apply to all things service.

46
00:05:23.770 --> 00:05:45.800
Fred Reynolds: I think it applies to everything. I mean, you could put a spin on it right, because everything that has a case or an incident or a anything can have a defined response, so it might kind of let on your sla is how you build those. So it's really how you define a service you want to provide, and then how you're going to respond to those. And this gets look, Mike proposed this blog today. But we kind of got excited before this got started, because

47
00:05:45.800 --> 00:06:03.750
Fred Reynolds: to me we, as we go through this, I want you to keep in mind that these conversations around. Meantime the response or and and the definition around this like this has been conversations I've been having for 20 plus years, and probably 20 plus years before me. This is still a problem for any customer of any size today.

48
00:06:03.750 --> 00:06:16.729
Fred Reynolds: I mean, it's interested in this much time that people still don't have a lot of this stuff handled. People still need help with this, and that's the whole purpose of like a platform like service. Now to help with this, so I won't go too deep, but I just find it a very applicable I'm I'm

49
00:06:17.120 --> 00:06:23.679
Fred Reynolds: happy, and this is one of those blogs like I'm happy to talk to because I lived it for so long. I'm trying to get better around this place. Pace.

50
00:06:24.300 --> 00:06:38.426
Andy Whiteside: So so this is the one Mike brought. He normally does. But, Eddie, I'm gonna come to you 1st with the the low tech side of Mtr. I think. You would probably be the best person to explain how you explain that to people from a business level as well as just from

51
00:06:38.970 --> 00:06:42.479
Andy Whiteside: you know, from from yeah. I guess from a business level, how.

52
00:06:42.480 --> 00:06:46.650
Eddie McDonald: I love it that you say the low tech one is good for me. So thanks for that.

53
00:06:48.010 --> 00:06:53.120
Andy Whiteside: Just because your present company is Mike and Fred. I'll I'll I'll let. I'll tease this one up for you. But I think you're knocking out.

54
00:06:53.120 --> 00:07:14.729
Eddie McDonald: Sure. Well, you know. So let's take a step back. Let's talk about what is Mttr. So we have an issue. And how long does it take to resolve that issue? So if we're talking about service now at its core, it is a productivity engine, that's what it's there for is to get people to work more efficiently. Visibility work in one place, and

55
00:07:14.790 --> 00:07:16.330
Eddie McDonald: too often.

56
00:07:16.370 --> 00:07:30.580
Eddie McDonald: you know, if we take a person's hourly salary, and there's there's numbers here we'll talk about. If it takes a half an hour to Mtr. An issue, then that's a half an hour times X, amount of people that are lost productivity.

57
00:07:30.580 --> 00:07:55.080
Eddie McDonald: And it's in. Fred just said it. It's a significant issue. It's been a significant issue since it has been around. When stuff breaks, people stop working, and and they get distracted, because now they have to go fix that thing, it's all real dollars that are being lost. So the low tech side of it is, people aren't working. When stuff is broken. We need to get visibility early.

58
00:07:55.080 --> 00:08:15.590
Eddie McDonald: We need to get fixes that are automated and get the people out of the fix as well. But when you're talking low tech, it's literally people on phones saying something is broken, and other people on the other end of those phones talking to other people trying to fix it. It's very low tech in most environments today.

59
00:08:17.080 --> 00:08:33.170
Andy Whiteside: Hey? And I want you to walk through these. I I wanna stage this for you, though real quick and I want Mike to respond, and Fred over the top. But like, I think, a lot of times, it's the person on the other end of the equation. If it's not urgent like, if they're not down, if they're not totally broken, I think they slow down

60
00:08:33.169 --> 00:08:56.060
Andy Whiteside: the process. But before we do that Mike Mike saved us a while ago, and I was too done to look. They had a note, a footnote, and they actually defined it for the sake of this article, the way the author meant it, and I think Mike said it. But I'm just Gonna repeat it. Mttr is a commonly used abbreviation in it. Services and operations that stands for mean time to repair, meantime to response, meantime to respond, and meantime to resolution.

61
00:08:56.434 --> 00:09:01.549
Andy Whiteside: I I guess it depends on your frame of reference as to which one you mean by Mtr.

62
00:09:03.000 --> 00:09:17.330
Eddie McDonald: I think generally it's it's resolution is is, how long does it take to fix it? Now? Now, I guess there are elements where responding is is for like a help desk. What is nttr, if there's a certain issue that pops up.

63
00:09:17.330 --> 00:09:39.340
Fred Reynolds: So so truly, I think that's what it's meant meantime to restore right to to res to resolve the issue. But all those steps in there which is so neat about this article, because we do need to go through these. What it's calling out here to percentages of why, that's what this is trying to say is, where are they today? Still, today in this this journey, and one of the biggest problems are still trying to solve. So I'll stop there. But I think these percentages really need to go over.

64
00:09:39.340 --> 00:09:54.690
Andy Whiteside: Mike, why don't you walk us through the graph as well as the numbers down below? And and when you find the one that applies to say me when it's not urgent. Aka Andy, cause I'm you know I don't respond to the for 3 days when somebody sends me something highlight where that one fit. But go ahead.

65
00:09:55.020 --> 00:10:05.909
Mike Sabia: So I mean, per this chart with the 5 orange percentages detection identification logging, you know, identifying what the issue is and and what this one

66
00:10:06.240 --> 00:10:21.379
Mike Sabia: concept this article does not talk about is deflection, you know. If a person could, you know, go to your your website, say, I want to report an issue, and and they're able to resolve themselves. That's deflection. And it's not going to be Mtr. Mtrs. Once the ticket is opened.

67
00:10:22.013 --> 00:10:34.020
Mike Sabia: But this 1st item of detection. Identification logging does touch a little bit. And and I think it's mentioned elsewhere in the article about proactive customer support, you know, identifying issues before the customer

68
00:10:34.070 --> 00:10:45.380
Mike Sabia: notices. It's an issue. If you can find out that a system is offline, automatically create it, resolve it. The customer may not even know it, or they may be able to see that they're reporting it. And we fix it 5 min later.

69
00:10:46.402 --> 00:11:05.789
Mike Sabia: So identifying it, submitting it categorization, triage, prioritization routing talks about like, Hey, once, you know, created the ticket, you want to classify it. So it gets to the correct group to work on it, you triage it to understand what's going on. You prioritize it. Say, hey, yes, this is a high issue.

70
00:11:05.820 --> 00:11:20.079
Mike Sabia: but it's only impacting one person versus maybe something that is, you know, just stepped down from high person. But impacting 10,000 people there, there has to obviously be a relative prioritization. And then, you know, per the characterization, the routing to the correct group.

71
00:11:20.080 --> 00:11:24.090
Andy Whiteside: Yeah, hey, Mike, the 1st one, you it has 12%. Here. You, you agree with that.

72
00:11:28.080 --> 00:11:30.080
Mike Sabia: yeah, I think that's about right.

73
00:11:30.320 --> 00:11:35.289
Andy Whiteside: Yeah, that that means 12% of the total time is spent in detection, slash identification and logging.

74
00:11:36.110 --> 00:11:36.730
Andy Whiteside: Yeah.

75
00:11:36.730 --> 00:11:57.440
Mike Sabia: I mean from an end user, you know, identifying the issue and then submitting. It is part of their part of their problem. How long does it take to go to the right place to open the ticket? How do you find out where you can open the ticket? If you have a problem with your refrigerator who you're going to call. That can absolutely be a part of time. But for us, hopefully, they know where to go. And and it would be smaller, I'd say, on average, 12

76
00:11:57.460 --> 00:11:58.720
Mike Sabia: is reasonable.

77
00:11:59.270 --> 00:11:59.599
Andy Whiteside: And then.

78
00:11:59.600 --> 00:12:00.180
Mike Sabia: And then.

79
00:12:00.180 --> 00:12:03.699
Andy Whiteside: That's part of that, too. And that's that's continuous throughout the entire

80
00:12:03.780 --> 00:12:05.140
Andy Whiteside: cycle. I would think

81
00:12:06.160 --> 00:12:09.060
Andy Whiteside: the entire time the logging piece.

82
00:12:09.160 --> 00:12:11.840
Andy Whiteside: Is it logging the initial issue? Or is that.

83
00:12:11.840 --> 00:12:12.570
Fred Reynolds: Yeah.

84
00:12:12.740 --> 00:12:15.560
Mike Sabia: I would say, logging the issue, opening the the ticket.

85
00:12:15.560 --> 00:12:16.280
Andy Whiteside: Okay.

86
00:12:16.280 --> 00:12:42.780
Fred Reynolds: I have a couple of comments with that. So so one it the the 1st thing coming in of somebody raising an incident, or we'll create, instance, for now, right? Detection, identification logging. I mean, it could come from. It depends on the source it's coming from, too. It could be so picking up the phone and saying, I have an issue. It could be something come from monitoring tools, and that has a login with it, and logs that go along with that. So I mean, I would say that you would hope that it's a lot less than 12% for someone to raise an issue and tell someone what's going on to create that

87
00:12:42.780 --> 00:12:53.610
Fred Reynolds: ticket or case for them. I think sometimes it becomes a lot more complex and takes time because of of all the information needs to be captured to create that problem right? The better tech section.

88
00:12:53.610 --> 00:13:06.760
Fred Reynolds: So auto detection is one thing, and then, I think you know, coming off of that to identify what the real problem is is probably why it goes up to 12 because it's auto detected. It should be quick. If it's something that somebody has identified. The problem is, it's gonna take a lot longer to create. That case would be my

89
00:13:07.100 --> 00:13:08.769
Fred Reynolds: my only thoughts on that.

90
00:13:10.500 --> 00:13:18.559
Andy Whiteside: So so we have the next category which Mike, you've already covered. Categorization triage prioritization and routing. You put that at 25%. That

91
00:13:19.475 --> 00:13:19.880
Andy Whiteside: that's.

92
00:13:19.880 --> 00:13:26.810
Mike Sabia: But they put a 25. I I would hope that that would be quicker. I I'm I'm surprised that the the you know

93
00:13:26.810 --> 00:13:50.860
Mike Sabia: I mean, triage is part of it, you know. Yes, you open the ticket. Maybe it gets auto categorized, you know. You prioritize you, Brad it. But the triage could take a fair amount of time. Say, hey, what exactly is going on? Somebody's reporting an issue with their VPN. Well, why is it something individually to them is a server down. Is it related to a schedule change? That? That's the pro part that I would say increases it.

94
00:13:51.160 --> 00:13:51.950
Mike Sabia: Yeah.

95
00:13:51.950 --> 00:14:16.330
Eddie McDonald: Especially if they don't have a tool like service now is using itun service mapping. You can see the impact upstream downstream of a server going down. You know you might not know you and I might be able to identify and triage an issue quickly. But if they don't have these tools in place that triage. So the 25% could be very valid and a not, you know, up to speed environment.

96
00:14:16.330 --> 00:14:42.469
Fred Reynolds: Well, I'll tell you from 10 plus years or like service desk and running manage services. I mean, that triage is that piece right? Categorization, prioritization and routing should be automatic. If you're using something like service now to your point, Eddie, for anybody out there that's not using a service now, it definitely changes it right? Because who knows how they're handling the routing, how they're prioritizing? But with tools like service. Now, you can auto set those values. But triage Mike's point. That's another pain point, right? You got to be able to triage and understand.

97
00:14:42.470 --> 00:14:47.540
Fred Reynolds: Real problem is and define that. Because if you can't define it. You can't get it to the right people, which means you can't route it.

98
00:14:47.540 --> 00:14:59.590
Fred Reynolds: You can't put it in the right prioritization because you don't know the effect or the business services that you're impacted. So so 25% to me, Andy is very reasonable. I think probably 2523% of that is on the triage place.

99
00:14:59.590 --> 00:15:03.500
Andy Whiteside: Well, like, yeah, 80% of the 25 is more is the triage.

100
00:15:04.152 --> 00:15:06.760
Eddie McDonald: Making up, numbers, now.

101
00:15:06.760 --> 00:15:11.379
Fred Reynolds: Like the same thing said before identification and then triage. And now we're up to the 3rd thing. So yeah.

102
00:15:11.380 --> 00:15:13.809
Eddie McDonald: 50% of the time it works every time.

103
00:15:16.350 --> 00:15:18.180
Andy Whiteside: Oh, you guys are doing fuzzy man!

104
00:15:18.180 --> 00:15:46.099
Eddie McDonald: So the 3rd one with that 30, the team engagement incident, communication collaboration that goes back to what I was talking about before people on phones, talking to other people on phones, shooting emails to each other. It's a lot of chasing your tail during that piece, and you can see that this is, you know, as far as this graph is concerned, the largest time Chunk is getting people together to figure out how to go forward with the fix.

105
00:15:46.290 --> 00:15:56.809
Andy Whiteside: Yeah. Like for me, I'm envisioning. If I had to call Fred or Eddie to talk about this communication would be 90% of the 30%. But if I had to call Mike, it'd be like 10% of the 30%.

106
00:15:57.082 --> 00:16:17.220
Fred Reynolds: You know. The thing is, though, it does show that out of the all the time you put into trying to resolve something to get something to close. They're saying the bulk of that, I mean 30%, or the the leading cause of that is team engagement, incident, communication and collaboration. Right? So what tools are around that to help someone be more efficient in that? And that's a big part of this.

107
00:16:17.220 --> 00:16:24.000
Andy Whiteside: So since we were letting Mike walk us through this, and Mike didn't get a chance to comment on this one comment, Mike, what is your thoughts on this one.

108
00:16:24.000 --> 00:16:25.179
Mike Sabia: Yeah.

109
00:16:25.720 --> 00:16:27.591
Mike Sabia: I would say, that's

110
00:16:28.130 --> 00:16:46.919
Mike Sabia: It's bad that it's so high for sure. And there are, you know, if you have customers, many customers reporting the same issue. And you have major major incident management or major issue management there are ways to facilitate the communication and collaboration. But yes.

111
00:16:47.488 --> 00:16:51.869
Mike Sabia: the to to Eddie's point. The amount of time it takes

112
00:16:52.020 --> 00:16:55.950
Mike Sabia: us to reach out to the correct people and pull the right people together

113
00:16:56.240 --> 00:16:57.320
Mike Sabia: can be high.

114
00:16:57.650 --> 00:17:05.510
Andy Whiteside: Is, is it fair to say this section here, the one we've been talking about engagement, incident, communication, and collaboration? That's where AI has the most promise.

115
00:17:07.329 --> 00:17:08.539
Fred Reynolds: And the one before.

116
00:17:08.880 --> 00:17:11.540
Mike Sabia: I would say, the second one is probably the the

117
00:17:11.550 --> 00:17:29.120
Mike Sabia: the 1st place, that there's opportunity, and some of that is not what we think of as generative. AI is just predictive intelligence. So the second one is more predictive intelligence. How do you auto categorize it? Based on keywords who it's coming from the number of people that it's impacting the like

118
00:17:29.520 --> 00:17:39.759
Mike Sabia: team engagement. I I'd see an opportunity for that to to get it to the correct people, and then, you know, notify the people. And pre, you know, automatically schedule meetings.

119
00:17:40.417 --> 00:17:53.789
Mike Sabia: But there's also opportunity in the in the last one, as well, you know, once you have written it up and you need to. You know, I know we're getting ahead of ourselves. But to to write it up and to summarize the issue and communicate that out. That's also an opportunity for AI.

120
00:17:54.330 --> 00:18:04.489
Eddie McDonald: Yeah, I don't know if the AI capabilities are there yet to be able to scan the challenges in your seem to be, or your or your

121
00:18:04.690 --> 00:18:12.680
Eddie McDonald: your back office to identify what the problem is, and then propose solutions. I don't know if it's quite there yet.

122
00:18:12.680 --> 00:18:23.400
Mike Sabia: I I will say that AI does come in for the 1st one detection. You know there are logs out there that will say, hey? This thing is trending up, but it hasn't hit your threshold.

123
00:18:23.510 --> 00:18:30.690
Mike Sabia: Do you want to wait till it hits the threshold for you to realize there was a problem, or do you want to have AI seeing? Oh, this is trending up.

124
00:18:30.760 --> 00:18:37.039
Mike Sabia: but isn't there? But there's another one that's just below, but it's completely stable. There's a great opportunity for AI there.

125
00:18:37.490 --> 00:18:38.180
Mike Sabia: Yep.

126
00:18:38.780 --> 00:18:49.930
Eddie McDonald: Right? Yes. Cause yeah. The cause that functionality exists today in service now. But there's only an alert that is sent out. If there's an upgrade due or something. It won't actually propose that solution.

127
00:18:50.710 --> 00:18:59.729
Fred Reynolds: Let's hit large on those solution types. Right? So I mean again, in general, I think it's there, like Mike said. Predictive intelligence has been there. People have used that before to help to

128
00:18:59.730 --> 00:19:21.710
Fred Reynolds: do some of that from a from an automation standpoint. But true AI and Gen. AI. I think we'll start seeing more use cases around that and how you use it with some of this communication type stuff, right? Summaries of issues. How do you kind of go through toward a resolution. How do you summarize that and get that out? To close that case, I think a lot of that can be used for some general AI. And communication back to the person who put the case in.

129
00:19:22.934 --> 00:19:29.049
Andy Whiteside: So yeah, kind of teed you go wait a minute with last one Mike. The last section here says closure and post incident, reporting.

130
00:19:29.290 --> 00:19:30.810
Andy Whiteside: It says 5%.

131
00:19:31.510 --> 00:19:32.155
Mike Sabia: Yeah,

132
00:19:34.100 --> 00:19:38.350
Mike Sabia: I I'd say, you know, summarizing it in order to give an update to the customer.

133
00:19:38.510 --> 00:19:41.100
Mike Sabia: 5% is reasonable.

134
00:19:41.873 --> 00:20:09.136
Mike Sabia: You know we've all seen tickets that have languished for weeks at a customer because, or at a at a partner or or customer, because it just takes so long to resolve it, but assuming that it's a a reasonably approached ticket summarizing it and closing it is about 5% seems reasonable. But again, AI is also ability to speed this up as far as summarizing the issue, summarizing the the communications into

135
00:20:10.125 --> 00:20:12.800
Mike Sabia: readable outputs for the end user.

136
00:20:15.990 --> 00:20:18.890
Andy Whiteside: Okay, the next section gets

137
00:20:18.970 --> 00:20:28.490
Andy Whiteside: to my point earlier and it talks about what percentage of Mttr is inactive time spent waiting for information or response.

138
00:20:28.880 --> 00:20:31.180
Andy Whiteside: Mike, you want to talk through the numbers they provide here.

139
00:20:31.180 --> 00:20:36.440
Mike Sabia: So this is quotes from people on thinking how much time is wasted.

140
00:20:36.450 --> 00:20:45.390
Mike Sabia: So 27% think that 50% or more time is wasted 42%. It says it's a quarter. 19% says it's 10

141
00:20:45.580 --> 00:20:49.049
Mike Sabia: and 12% says it's it's almost no wasted time.

142
00:20:49.646 --> 00:21:03.119
Mike Sabia: I'm assuming that this question is asked of the It departments who are working it? Not, you know, the end user. The end user is not going to normally know that, but might be wondering how much time is being wasted. Why haven't I got response back?

143
00:21:06.740 --> 00:21:28.770
Mike Sabia: it's all perceptive, you know, an end user. I might think that it's it's wasted. I I recently opened some tickets, and I'm like, Hey, where? What's my status? Not with with internal, but with service now itself saying, Hey, what's the status of my ticket? And and I don't get an answer and a lot of it's maybe that person hasn't prioritized my ticket across. However, many other tickets that are assigned to them.

144
00:21:28.850 --> 00:21:31.820
Mike Sabia: it to me that was a waste of time, but

145
00:21:31.890 --> 00:21:33.110
Mike Sabia: or

146
00:21:33.150 --> 00:21:39.219
Mike Sabia: person working on it, maybe it's just an efficient use of what they were assigned, and and their availability so.

147
00:21:39.220 --> 00:21:56.910
Eddie McDonald: I I feel like it's implied that the question was posed to the folks working on the issue and the takeaway. If you get out of the granularity of these numbers, 90% of the people question says, there are significant wasted time in the resolution.

148
00:21:56.910 --> 00:22:18.730
Eddie McDonald: Yeah, it's a big deal. I I mean, it's it goes back to what Andy and I were saying at the beginning that this is every hour. And the next segment is, gonna talk about what that Mttr is. If it's 30 min to 2 h. If we average out an hour times X number of people, these are real dollars that these issues are burning through.

149
00:22:20.580 --> 00:22:48.860
Fred Reynolds: Look. I think I think those percentages to me would seem accurate. But again, to Mike's point is perception, right? So 50% of times wasted. I feel like that. Probably everything I open because you always feel like half the time you're trying to re-explain something you've already said is an issue, or you're waiting for people to figure out how to go about fixing it. It's usually not how to fix this user identifying and triaging it. So you have to think that if half the battle is actually articulating what the problem is and triaging it, then certainly you cut 50% of your waste of time out by trying to get to that quicker.

150
00:22:48.990 --> 00:22:50.209
Fred Reynolds: That would be my takeaway.

151
00:22:50.210 --> 00:22:57.982
Mike Sabia: I I haven't seen it with many customers, but the 1st the 1st company I work for when I got into service now, which is 11 years ago,

152
00:22:58.570 --> 00:23:01.079
Mike Sabia: as an education company. The way they

153
00:23:01.090 --> 00:23:04.260
Mike Sabia: did their changes is they actually looked at how

154
00:23:04.300 --> 00:23:13.519
Mike Sabia: much, how many impacted user minutes there were like, Hey, this took an hour or this took 10 min, but multiplied by how many people were impacted

155
00:23:13.680 --> 00:23:28.339
Mike Sabia: and based on that that calculation. Then they would determine. You know, when a change could happen. Is it something that could happen during the day, or has to happen the weekend because of of just how many impacted minutes there were of an inch issue

156
00:23:28.390 --> 00:23:30.060
Mike Sabia: as a result of it.

157
00:23:30.420 --> 00:23:33.440
Mike Sabia: a planned or unplanned change. So

158
00:23:33.980 --> 00:23:35.469
Mike Sabia: it's interesting.

159
00:23:36.147 --> 00:23:41.519
Mike Sabia: But by itself, without knowing how many people it's impacting.

160
00:23:43.060 --> 00:23:59.670
Mike Sabia: I don't know. I mean, you know, is it 50% time wasted? But it's a a low priority issue that's quite different from some super high critical issues impacting thousands of people or systems offline. And and I don't know. The statistics fully represent that.

161
00:24:00.230 --> 00:24:17.649
Eddie McDonald: Yeah, I think these I mean again, just looking at the numbers. I think these are rounded up, and this are general. Yes, I mean. I know personally that when I in my life, when I try to explain, like what's wrong with my marriage, 50% of that time is wasted, you know, that's just time that I'm never gonna get back.

162
00:24:18.470 --> 00:24:20.237
Fred Reynolds: Is that your 50% or something.

163
00:24:20.490 --> 00:24:25.838
Eddie McDonald: Yeah, yeah, my 50% is all wasted time trying to explain that problem.

164
00:24:26.490 --> 00:24:28.449
Andy Whiteside: I'm not touching that one. Okay.

165
00:24:29.600 --> 00:24:30.000
Andy Whiteside: that's okay.

166
00:24:30.000 --> 00:24:31.329
Fred Reynolds: Don't want my mouth moved, but go ahead and.

167
00:24:32.490 --> 00:24:40.539
Andy Whiteside: So it says, what's the problem? And then, for instance, problems what are the biggest challenges to effective incident, response and management?

168
00:24:40.710 --> 00:24:42.199
Andy Whiteside: Select 2

169
00:24:42.584 --> 00:24:47.299
Andy Whiteside: Mike again, I'll let you lead us on this. But what what if? What are people

170
00:24:47.500 --> 00:24:49.529
Andy Whiteside: saying? The problems are.

171
00:24:49.830 --> 00:25:03.069
Mike Sabia: So since you can respond to 2, these numbers should app, add up to 200. So looking at the 1st one, it says, 51% of people say that getting the right teams engaged in collaborating is critical. And I would agree.

172
00:25:03.472 --> 00:25:21.740
Mike Sabia: You know, I I've opened tickets where I'm like, Hey, I don't know if it's I. I opened it against the correct team. And so sometimes I I open 2 tickets. Because I'm like, well, probably one of these will get it quicker, because I need a quick answer, you know. Being able to get it to the correct team is is absolutely high critical importance.

173
00:25:22.330 --> 00:25:48.399
Mike Sabia: Because you can't start until it's to the right team second, lack of a unified view and dependency mapping of service elements. That's 39%. And this goes back to one things that Eddie mentioned. You know, a person calling up doesn't know that there's a load balancer, web server or the like down. They just know that their service is having an issue. Their VPN a service is having an issue. Their email is having an issue their connectivity to some systems having an issue, and to be able to

174
00:25:48.400 --> 00:25:59.530
Mike Sabia: lock or associate that service to the dependent items and then identify, you know which issues or which Cis might have changed recently. That could be.

175
00:25:59.560 --> 00:26:09.110
Mike Sabia: you know, causing this is is high, and and I would probably say, this is in reality, probably one of the highest, but it is ranked second.

176
00:26:09.250 --> 00:26:36.459
Fred Reynolds: So my, I was gonna pause you for seconds, those number 2. I'm glad you just said it, because that's that's the 1st thing popped my mind. I'm surprised by that, because the reality is what Mike said, it is that number 2, the unified view, understanding what's been affected service map and understand what what's being impacted. That's the number one thing that's going to delay your time, because in order to find that out, sometimes you have to get teams together. Which teams do you get together like it kind of goes hand in hand, but really not understanding what's being impacted

177
00:26:36.460 --> 00:27:00.819
Fred Reynolds: is what takes the most wasted time perception, because once you find out the person, let's just say it ends up being a networking issue, a bad port in somebody's office, but they think it's a hundred things else by the time you get to identify that that person could probably fix it very quickly. But you spend a lot of time identifying what's been impacted. So I would like Mike, you said it. I was gonna say, if you didn't like that number 2 instead of 39 should probably be like 80, and the rest could fall behind that, in my opinion. But.

178
00:27:03.338 --> 00:27:18.670
Mike Sabia: Right? So the 3rd one ha! Is understanding the impact. And when I open tickets, whether it's internally or with service now, or you know about my refrigerator. I always start saying, You know, I don't just say, Hey, this is the issue. I'm saying, Hey, this is my impact. I'm trying to do this I can't.

179
00:27:18.960 --> 00:27:25.059
Mike Sabia: And then I go into the details of what I'm seeing, so that people can understand what I'm what I'm dealing with.

180
00:27:25.720 --> 00:27:28.320
Mike Sabia: The the reason why this is important.

181
00:27:30.160 --> 00:27:41.170
Mike Sabia: I. I think that as a receiver of tickets, not knowing that context where you have to go back into the custom. Say, Okay, I'm I'm seeing what you're seeing. But but why is this important

182
00:27:42.030 --> 00:27:44.180
Mike Sabia: that that could be fairly large.

183
00:27:45.870 --> 00:27:50.380
Mike Sabia: going on to the 4th one inefficient manual processes and bottlenecks.

184
00:27:51.310 --> 00:28:08.119
Mike Sabia: for sure. I mean automating these tools, whether it's orchestration to fix the issue or having knowledge articles to describe the issue. You know, people have had this problem before. Why am I not able to find a quick Google answer or see it? This, in my, in my knowledge base that could be considerable.

185
00:28:08.600 --> 00:28:09.200
Mike Sabia: A lot.

186
00:28:09.200 --> 00:28:21.919
Eddie McDonald: I can that one's actually really important as well, because you know, not to work in a commercial in the middle of this, podcast but every every conversation we have with our customer begins with process.

187
00:28:21.920 --> 00:28:49.560
Eddie McDonald: We are not going to build a platform out to something that's that's antiquated and broken. So inefficient manual processes, we can practically automate any process. I mean, it's a blanket statement. There's some things we can't. But 98% of the time we're going to be able to automate that and remove those bottlenecks. So that is something where we start the conversation which by this this takes care of 31% of those challenges right there by automating these processes.

188
00:28:50.430 --> 00:28:51.150
Eddie McDonald: Okay.

189
00:28:52.511 --> 00:29:04.460
Mike Sabia: The second to last is too many alerts, as if you had, like an alerting system arm system that's reporting on issues. And it's just spamming you with tickets. It's hard to know what's most important.

190
00:29:04.680 --> 00:29:08.899
Mike Sabia: So there is a certain amount of noise that one has to deal with.

191
00:29:10.300 --> 00:29:22.900
Mike Sabia: I could see why, that's important. And hopefully, as once you start, seeing that you start having some filters on items to indicate whether it's automated whether people are actually, you know, real people are reporting it.

192
00:29:23.320 --> 00:29:28.520
Mike Sabia: whether it's just you know, flipping over and over and over.

193
00:29:28.890 --> 00:29:30.420
Mike Sabia: That's 19%.

194
00:29:30.490 --> 00:29:38.775
Mike Sabia: And then the last one of the biggest challenges is Silas systems and tools. And of course, that's a a fantastic

195
00:29:39.680 --> 00:30:02.249
Mike Sabia: ability of service. Now that it brings everything into a single pane of glass, that instead of having one system for this, and one system for that, one system, for the 3rd thing, you can see everything together. You can see your incident, you can see how it's tied to your scene to be. You can see how it's tied to your users, whether it's associated with projects, or or the like, or everything being able to come together in service now is, is

196
00:30:02.470 --> 00:30:08.269
Mike Sabia: it is able to reduce that percentage for sure for any service. Now. Ticket.

197
00:30:08.490 --> 00:30:31.629
Fred Reynolds: And you know one thing I like one thing I love about our team, and here in our service. Now, partner, says Integrs, you look at all of those. What are 6 items? Right? I could take each one of those and kind of identify, you know, within the applications of service. Now within the platform, how it can help you solve these things even because of too many alerts. Right? There's so much things we've done in the past to help with that, you know, between stacking the business services. Aspect of it. Right? You know, being able to

198
00:30:31.630 --> 00:30:55.389
Fred Reynolds: to be able to take one instance, a real issue, and then fold up 45 other things underneath it, because you know that that's not the real cause. I mean, there's so many things that we can look at that service now can solve, for that's going to be the next part. But that's 1 thing I love about our team is that we have so much experience of years of not only implementing service now in technology workflows, but also being in the industry like Mike said, seeing that in the companies we work for and doing it real time.

199
00:30:55.710 --> 00:30:56.080
Andy Whiteside: Yeah.

200
00:30:56.080 --> 00:31:21.029
Eddie McDonald: You know, Fred's a great point. I mean, you and I are working on this deal right now, what's actually closing? It's a global Satellite company. And we've been scoping this work. They're going to source to pay from from opportunity creation to implementation. 90% of the last 3 months has been talking about their processes and streamlining those removing those bottlenecks before we ever talk about the platform. So

201
00:31:21.030 --> 00:31:27.850
Eddie McDonald: that is separate from this Mttr. Conversation. But it's a thread that runs through everything that we do.

202
00:31:28.210 --> 00:31:29.120
Fred Reynolds: Exactly.

203
00:31:29.303 --> 00:31:36.646
Andy Whiteside: You know. For me it's most exciting. 2 things, one, Fred made a comment. We've never lost a customer that on the service. Now side that that's close. It may be a hundred percent true, but it's really really close.

204
00:31:37.181 --> 00:31:57.850
Andy Whiteside: But what I love about this space and it's just the reality of it is if you go in and you solve number 3 here, business context, understanding the impact. And that number goes down, all the other numbers go up because it's still just a percentage of the overall problem, and the problem gets better and better and better. But it never goes away. It just moves from 1 1

205
00:31:58.120 --> 00:32:00.330
Andy Whiteside: answer to the other.

206
00:32:00.370 --> 00:32:04.090
Andy Whiteside: and you're just whittling them all down the best you can. But you know it's it's still

207
00:32:04.280 --> 00:32:04.830
Andy Whiteside: it'll.

208
00:32:04.830 --> 00:32:08.350
Eddie McDonald: And eventually they'll stop asking the questions. That's the goal.

209
00:32:08.350 --> 00:32:32.389
Fred Reynolds: Well, truthfully, guys, I lived in a state for many, many years where I had that type of status there, like those type of measurements, and over here the measurements on our on our meantime resolution numbers. Right? So how do you drive those numbers down, or how do you put it within the sla time, as Mike mentioned. Right you. You set your sla's, and you have to measure against that. And as you attack these things, so maybe it is that people getting the teams dead better together. And you implement some things within service. Now to

210
00:32:32.390 --> 00:32:50.609
Fred Reynolds: help with that skills based routing? Who's the right people. How do you get it to them? Right? How do you notify them? How do you make sure they're responding? And all those I mean, all those things are really necessary, and you will see those numbers going down here. And then why? Because those numbers drop over here and you tackle the next thing. It's a never ending battle. Once you fix a couple of things, something else is going to pop up.

211
00:32:50.610 --> 00:32:50.970
Andy Whiteside: What?

212
00:32:50.970 --> 00:32:51.350
Eddie McDonald: Right.

213
00:32:51.350 --> 00:32:59.319
Andy Whiteside: Like it's like whack a mole. But but the moles are getting smaller and less impactful. But yet there's always going to be moles to whack.

214
00:32:59.320 --> 00:33:15.810
Fred Reynolds: When you get to a point where your Mttr is within your Sla range, and you don't have to discussion anymore. But it's not that difficult to to attack your Mttr. For most companies, if you have a solution like service now, outside of that, I can't really speak to it right. But I had to implement service now to get there.

215
00:33:15.810 --> 00:33:20.260
Andy Whiteside: Have visibility and the tools. You're right. If you don't, you ain't never gonna solve it.

216
00:33:20.260 --> 00:33:21.110
Fred Reynolds: That's correct.

217
00:33:21.110 --> 00:33:27.929
Eddie McDonald: Well, it's like my drinking problem. My 1st step was acknowledging that I had a problem, and then it's easy to fix.

218
00:33:28.530 --> 00:33:29.130
Fred Reynolds: Yup!

219
00:33:29.590 --> 00:33:31.639
Andy Whiteside: Man. Here we go down that one, though.

220
00:33:31.640 --> 00:33:33.860
Eddie McDonald: I, yeah, dude, yeah, I I mean, I didn't.

221
00:33:33.860 --> 00:33:34.710
Fred Reynolds: But I'll sleep in there.

222
00:33:34.710 --> 00:33:36.715
Eddie McDonald: I'm all over the place today.

223
00:33:37.050 --> 00:33:39.280
Andy Whiteside: Think I think I know what the wife conversation.

224
00:33:39.280 --> 00:33:40.110
Fred Reynolds: I could.

225
00:33:40.110 --> 00:33:40.810
Andy Whiteside: And I would.

226
00:33:42.470 --> 00:33:44.320
Fred Reynolds: Can we do another podcast on Eddie.

227
00:33:45.310 --> 00:33:46.300
Eddie McDonald: Michael.

228
00:33:46.300 --> 00:33:47.300
Andy Whiteside: Oh, you hadn't comment!

229
00:33:47.300 --> 00:33:50.220
Mike Sabia: I am. Gonna add one piece

230
00:33:50.230 --> 00:33:51.000
Mike Sabia: and

231
00:33:51.980 --> 00:33:54.671
Mike Sabia: And now Eddie's distracted me.

232
00:33:57.590 --> 00:34:22.979
Mike Sabia: I wanted to say, oh, right. So even if your Mtr. Is going down or is good. That doesn't mean that there might be certain groups where it's it's going higher, and that could be a manual effort. Hey? Let me go look at all of my teams, and maybe do Mtr. By each one. But service now, going back to the AI capability, there are AI capabilities that will help you identify those teams. You don't have to wait through the data.

233
00:34:24.489 --> 00:34:25.219
Fred Reynolds: Good point.

234
00:34:26.690 --> 00:34:46.529
Andy Whiteside: Alright last section. Here we're running low on time, and I'm sure our listeners are either enthusiastic or gone to sleep one or the other. It talks about finding a realistic solution. And I like that. They call it a realistic solution, not just a solution. Because, as we were just pointing out, it's it's it's not solvable. It's just we can make it better. Mike. Go ahead.

235
00:34:46.870 --> 00:34:47.360
Andy Whiteside: Well.

236
00:34:47.360 --> 00:35:07.069
Mike Sabia: This is interesting. It talks about, of course, you know, doing information, sharing collaboration, cross functional workflows to address these challenges, but they go into the fact that most it leaders expect that outage, frequency, and duration would continue to rise because of how much stuff is going on, but that an intriguing 18% of

237
00:35:07.080 --> 00:35:16.238
Mike Sabia: the panel counter trend ran counter trend staying. That instance actually have decreased, due to proactive systems that have been put place, you know.

238
00:35:16.650 --> 00:35:38.059
Mike Sabia: if we're talking about what I mentioned at the beginning, the deflection of tickets, you might see that overall. The number of tickets are going down because you have those deflections. But that might mean that the length of your tickets might be going higher because the remaining tickets are maybe more complex

239
00:35:38.330 --> 00:35:42.749
Mike Sabia: multiple value multiple issues coming on the plate here.

240
00:35:43.759 --> 00:35:53.359
Mike Sabia: Going to the 3rd paragraph, you know, service now, absolutely offers many robust weapons in the battle from predictive intelligence to more advanced AI

241
00:35:53.390 --> 00:35:54.274
Mike Sabia: to

242
00:35:55.730 --> 00:36:01.219
Mike Sabia: the ability to do. You know, major incident management communication.

243
00:36:01.370 --> 00:36:12.340
Mike Sabia: the ability to have that uniform unified platform in order to get rid of some of those silos. You can't go into all of the service style capabilities in in just a

244
00:36:12.430 --> 00:36:23.879
Mike Sabia: brief blog to remediate these issues. But Servicenow Platform is absolutely trying to address Mtr. And all the topics that we've discussed during this blog today.

245
00:36:24.090 --> 00:36:24.740
Mike Sabia: Yeah.

246
00:36:24.740 --> 00:36:41.171
Eddie McDonald: Yeah. And and you know, at its core. And Mike just touched on, it's the unified platform, I think, is these is where we start. You know you can collaborate if your operations team your help desk, your end users. Your leaders are all on the same platform, working in the same plane of class

247
00:36:41.710 --> 00:36:56.340
Eddie McDonald: life just gets simpler, you know, is just is, especially when you get visibility into your your your organization, all your your seem to be all of your org. Your service mapping is all in one place.

248
00:36:56.340 --> 00:37:12.289
Eddie McDonald: then these decisions and these resolution times will naturally go down. It's just a it starts with a simple solution which is a unified platform. And then we can scale into those other areas where those those percentages were high.

249
00:37:12.290 --> 00:37:39.240
Fred Reynolds: And I. And I wanted to say this, too, I think finding a realistic solution has to come with also the investment, a realistic investment from the people trying to solve the problem. You know, I think that when you have a platform like service now, and you're trying to really solve for problems. I think that's the biggest thing that I see is a lack of investment and time to make those things get corrected. If you have a lot of issues with issues, with team collaborations or triage and those types of things

250
00:37:39.240 --> 00:37:59.909
Fred Reynolds: you really have to spend the time like, it was important for us to spend 3 months with the customer, to understand what their real process issues are. What's the bottleneck? Because if we don't find that out or fix that and putting a tool into many types, not even going to solve any of that stuff. Right? So I think it's a matter of somebody has to have a realistic solution by realistically looking at the problem at hand and understanding how we need to solve that. And I.

251
00:37:59.910 --> 00:38:01.460
Eddie McDonald: Yeah, sorry. That's.

252
00:38:01.610 --> 00:38:11.999
Fred Reynolds: Yeah, but I would say, service now is toolbox. Right? I'm I'm sold. I quit my other job to come here and just concentrate on service. Now, for that reason it is a Swiss army life. It can solve all these things we mentioned right.

253
00:38:12.180 --> 00:38:31.740
Eddie McDonald: Yeah, Fred, I think the spot on point. I think it's really important to understand that this is not a Band-aid approach. This is a strategic solution to an overarching problem. And it's not gonna happen in a day. It's gonna it's organizational change. It's changing hearts and minds. It's changing platforms. This is a big deal to a long term solution.

254
00:38:31.740 --> 00:38:46.709
Fred Reynolds: The long term solution with digital transformation, culture change and everything. I mean, it starts somewhere right? And you find your biggest problems. And you try to prove that and solve it? And again, Nttr. Is a major problem for everybody. In my opinion you just either have it solved or you don't.

255
00:38:47.020 --> 00:38:50.130
Fred Reynolds: Alright, that's my final comments, Andy, I mean Andy.

256
00:38:50.790 --> 00:38:52.205
Andy Whiteside: Well, maybe

257
00:38:53.620 --> 00:38:54.970
Eddie McDonald: You mean.

258
00:38:54.970 --> 00:39:01.599
Andy Whiteside: Earlier sla's. And I just wonder, from y'all's experience do you find people coming to us with defined sla's? Or is that

259
00:39:01.940 --> 00:39:02.700
Andy Whiteside: typically.

260
00:39:02.700 --> 00:39:10.840
Eddie McDonald: Yeah, we'll have something. It's usually generic. The the problem comes in when they have the sla is the same for an incident, or request

261
00:39:10.990 --> 00:39:16.510
Eddie McDonald: those 2 things. There's oil and water. They're not the same. But yeah, they generally have something to find.

262
00:39:16.730 --> 00:39:38.190
Fred Reynolds: I think what's important about sla is. I will say this because I think it's a matter of me dealing with this for so Long Mike's mentioned deflection a couple of times. I think that's very interesting, right? Cause I feel like that couple of the providers for me. Let's just say cable provider, for instance, right? Their their tactic is deflection, and it makes you want to give up on stuff right? So that that's a man I was kind of losing a little bit.

263
00:39:38.190 --> 00:39:49.190
Mike Sabia: Be good and bad deflection if you can get the person to self self resolve through like a service. Now, Portal fantastic. But yeah, if you just want to kiss, kick the can down the road as Fred is laying.

264
00:39:49.350 --> 00:39:50.350
Mike Sabia: That's a problem.

265
00:39:50.680 --> 00:39:51.630
Fred Reynolds: That is a problem.

266
00:39:51.900 --> 00:40:01.080
Eddie McDonald: Yeah, or those those those voice prompt loops you get in and you can't get out of. That's a great way to deflect a ticket from ever being created.

267
00:40:01.080 --> 00:40:02.289
Fred Reynolds: That's exactly right.

268
00:40:03.450 --> 00:40:21.069
Andy Whiteside: Hey? Let's see the the one last thing I was gonna say, we get a lot of pushback on service now being expensive if we apply what we've talked about here. And we're solving problems faster. And we're bringing, maybe replacing other tools in the process. And we have one unified platform to do this with Eddie. Is it expensive.

269
00:40:21.070 --> 00:40:30.970
Eddie McDonald: Absolutely not. And that is such. I I look, I love that question. I love that comment. Service now is not expensive. People are expensive

270
00:40:30.970 --> 00:40:55.369
Eddie McDonald: platform. Technology is cheap across the board. Whether it's a laptop or a platform. Technology is cheap. It's our job to show you where the value is. If you feel the service now is expensive. Whoever you've spoken to in the past has not done a good job of showing you where you're gonna ultimately save that money increase productivity, increase visibility, you know. Ticket deflection. Mttr.

271
00:40:55.370 --> 00:40:59.510
Eddie McDonald: All of this value. Without a doubt its service.

272
00:40:59.510 --> 00:41:20.550
Eddie McDonald: It might not look cheap on paper, but when you look at the value of what you're buying, 100% is cheap, I'm very passionate about that, because that is that is something that's come up over the years is too expensive. No, is because the people, the consultants have gotten lazy, explaining where the value of the platform is.

273
00:41:20.550 --> 00:41:27.550
Fred Reynolds: But to Eddie's point. If you could spend $50,000 to to create some automation or to help

274
00:41:28.150 --> 00:41:31.579
Fred Reynolds: a automated process to help solve Mttr.

275
00:41:31.920 --> 00:41:44.829
Fred Reynolds: you know, and you put that up against the number of hours spent by the people like Eddie's Point. People are expensive, I guarantee, would justify itself tenfold, because once you put a solution in place that can solve for that, that's a lifetime of that process.

276
00:41:44.830 --> 00:41:59.260
Eddie McDonald: Yeah, there, there's a reason why 88% of fortune, 500 companies or service now users, you don't think they do their due diligence, and they spend 7 8 digits on the platform licenses. So it's 100%. The values there. Yup.

277
00:41:59.940 --> 00:42:01.530
Andy Whiteside: I knew I could get Fred to go again.

278
00:42:04.140 --> 00:42:07.820
Andy Whiteside: Mike. Mike, you're and only your final thoughts.

279
00:42:12.240 --> 00:42:22.020
Mike Sabia: I I think that Mtdr. Is a fantastic metric. There are other kpis that come into place if you're doing implementation.

280
00:42:22.110 --> 00:42:35.480
Mike Sabia: you know. Yes, Mtr. Might be one of the things you're trying to address. But there might be other kpis that you want to look at, and if we come and do an implementation for you as a customer, we will be discussing those as well.

281
00:42:36.490 --> 00:42:41.409
Andy Whiteside: I like the In Ttr conversation, just because it's gonna it's gonna impact user perception and

282
00:42:41.610 --> 00:42:43.989
Andy Whiteside: user perception is just massively important.

283
00:42:45.820 --> 00:42:48.690
Andy Whiteside: Gentlemen, thank you, and we'll do it again in 2 weeks.

284
00:42:48.690 --> 00:42:52.423
Eddie McDonald: You know I had like 4 more jokes keyed up. Just so, you know.

285
00:42:53.620 --> 00:42:56.625
Fred Reynolds: And for our podcast we're starting on Eddie's life

286
00:42:57.450 --> 00:42:58.670
Fred Reynolds: every other week.

287
00:42:58.670 --> 00:43:00.789
Andy Whiteside: We'll put that in the outtakes or next week.

288
00:43:01.830 --> 00:43:04.300
Fred Reynolds: Alright! Thanks everybody. Thanks, John.