Join Scott Pross, Vice President of Monalytic, a SolarWinds company, for a discussion on real-world solutions utilizing the Service Desk application. Listeners will learn how to stop repeating processes over and over and get more information from the end user to resolve issues quickly and set up proper workflows to get the right data in front of the right people.
Corey Baumgartner
On behalf of SolarWinds and Carahsoft, we would like to welcome you to today's podcast focused around using Service Desk to speed up ticket resolution times where Scott Pross, Vice President of Monalytic, a SolarWinds company, will discuss real world solutions utilizing the Service Desk application.
Scott Pross
Good afternoon, everybody. Welcome to Using Service Desk to speed up the ticket resolution times. So, there's a little bit about myself. My name is Scott Pross. I'm the Vice President of Technology for Monalytic. I've been doing solar winds for about 16 years now I learned it when I had to build a NOC from the ground up for a billion-dollar company, we had a 99.99% customer facing SLA, that gave me four minutes and 37 seconds of downtime a month for 33,000 devices. So, as you might imagine, you get pretty good with it, when you have that kind of pressure on you. That said, you know, obviously, we had a lot of tickets that came in during that time. And we had to deal with those tickets. So, we use various ticketing systems throughout that period. And we came up with a process to really help us succeed, and really get to minimizing our SLA, or what we used to refer to, as are MTTR mean time to resolution. So as we were discussing that, you know, we kind of put some, some pen to paper here and came up with how can we help you guys are going to be the, you know, specific techniques that you can do to minimize the amount of iterations that you have to go through to close a ticket. So that was really the real purpose here. So, we're going to talk about the iteration issue. And so, I'm curious to find out from people, are you guys actually utilizing SL A's, you know, and they're not manager, I used to hate them, because, you know, either met them and my, for me, my bonus was tied to them, or you didn't need them. And, you know, it was a point that people started questioning whether or not you're in the right position. And if that happens, we usually met ours, but I learned to really appreciate SLAs, because they not only held me to a theatre and my interest in her, but it also helped to hold the other team to esteem my other team Swift, as well. And so that became very important. And I'm seeing that most of you actually do utilize it. So, let's talk about what is the iteration issue? What is it that we're trying to solve here. So, iterations are really bad for the ticketing process, for multiple reasons. And some of these are obvious. And some of these might be a little bit less obvious as we go through them. First of all, it's obviously going to take longer to close the ticket, you know, like it or not our job, you know, handling a ticket flow at handling tickets to come in, there's really tied to two things, how quickly it gets closed, and what quality, you know, information do we provide back to resolve the issue, because if you don't resolve it, it doesn't matter how quickly you do it. And if you do resolve it, but it takes an inordinate amount of time, that causes a huge problem and itself, and it causes frustration from the side of the customer. The second piece of this is it creates, you know, iterations create a perception that support doesn't have a have the proper expertise with the product. You know, when you call up, a lot of times as a customer, you expect a direct answer, you expect them to be aware of it, you expect them to know where to go to look for it, it's an expectation that we actually have, you know, when you open up a ticket with a vendor, if you're opening up a ticket, for somebody to solve your problem, have a hardware software problem on your network, you expected that person has the expertise. And the more iterations you go through the less feeling of security that that end user or that customer has, because the iterations tend to say that they don't know what they're looking for, or they don't know how to find it. So, by cutting down on simple iterations, we can allow for when we do need those iterations that when they actually count, when we actually have to get more information, we can utilize those because you're always going to have some iterations, you're never going to get rid of all of them. But if we can minimize the iterations on less important parts of the workflow and concentrate on when we really need them is kind of like using, you know, you might be given a Get Out of Jail Free card and monopoly. You only want to use that when you absolutely need it. You know, if you're capable of maybe paying the $50 to get out of there, you may do that instead. So, we want to use those iterations, very sparingly. When we absolutely need them. And then finally, users or customers may attempt to less than perfect self-help strategies. You know, I'm guilty of this too. I was having an issue, and my vendor wasn't getting back to me. Suddenly, I started to look for my own workarounds. How, you know, do I have other tools in play, that can help me solve this problem? Without having to deal with the vendor? Because the vendor wasn't able to answer, you know, my question? Or even worse, do they start to look for another way to do it with do another tool, you know, that too, could be a huge issue for you. So, you don't want your customer looking for their own solutions in this case, when you're not able to give them the answers that they need. And that is really, because it's just going to cause them to get an imperfect solution. And it's also going to cause a dissatisfaction with either your product or your support, or whatever it is that you're offering. And again, it shakes our confidence here, and we don't want to do that. So, let's talk about the difficulties of the ticketing process here. Okay, and what makes this so difficult, why, why is it that we have to do this? So, there's really several steps to making this easier for ourselves. And the first one, we're going to talk about each one of these in depth, but I kind of want to go over, you know, what are they and then we'll dive deeper into each one of them. The first one is collecting the necessary data. And I know this really sounds like a no brainer, yes, I know, I need to collect the necessary data. But as we dive into this, we're gonna figure out what does that actually mean? What do we have to actually provide the end user with to get the information we need to quickly solve the problem with a quality answer? Next piece is getting a ticket in front of the right people, again, almost a no brainer, yes, the right person needs to be looking at the ticket, so the person can be solving it. But again, we want to go back to this and say, Okay, we want to make sure that we have the right resource, dealing with this particular ticket, so that we can close it out. And we're going to dig a little bit more into what this means. And I've got to tell you, this can be a huge, you know, time sink for you aware there SLA times go in just getting this piece done. So, you know, the first one is obviously a huge time timestamp. But this is also a very large chunk of time, where things are just waiting. And not only that, they're not waiting for a good reason. You know, this is one of those things, if you set it up, right, it should be ultra ultra quick. But it can just sit there because we don't have the right resource, looking at, at the ticket that they need to look at. And then asking the right follow up questions, you know, making sure that we're talking to the customer asking those right questions that we're going to talk about ideas and methodologies that we can use to really push this forward. Because there's things that we can do to make sure that we’re asking the right question but be to save time on follow up questions. And again, cutting down on those iterations. Because if you cut out two or three iterations for each one of your tickets, a lot, in a lot of cases, you're talking about days or hours off of your SLA. And as I tell people, the lower you can get your, your time's the better off you're going to be. Finally, we have provided the correct troubleshooting steps. And this is probably the most frustrating one. Because a lot of times people don't understand that they need to be you know, the ticket, engineers don't understand that they have to make sure that everything that they provide is correct. And if you missed a step here, you're gonna take some heat for it. So, the whole objective here is to avoid that, and to provide the correct information. So, let's talk about collecting the necessary data. Because that's really our next, our first big topic. So, we want to get what we need upfront. That means when our user or our customer is opening up the ticket, we want them to we want to make sure that we're pulling every piece of information out of them that we could meet, because this first iteration, this is a first chance for them to explain the problem. Provide us logs, provide us as much analysis as possible. But as we all know, from experience, they don't. Their you know, their first reaction is to go ahead and say it's not working. It's broken. Well, we want to dive deeper into that. So, we have to make sure that we provide that information. So next, and this is a feature in service desk that is underutilized but really should be utilized by everybody and that is utilizing dynamic forms here to get information based on the selections made during the ticket opening process. So if somebody says to you, hey, I have a hardware problem, and they feel like hardware problems are dropped down, maybe the questions changed now that you're going to display to the end user, maybe you're going to be asking them things like, what you know, what's your serial number of your of your computer? What's the make and model of the computer? What kind of information do you want to gather, you know, you can do this multiple levels. So, if they select a Mac, perhaps you're going to collect more information. And so, you can have that hierarchy built in here, where you can say, if they go this way, we go down this path. And if we go this way, we go down this path. And this is where you're collecting the right information. This is where you can shine. Because you have the ability here to build out a dynamic form and a workflow here, that's going to collect as much information as possible. Again, we want to cut down on these early iterations of adding, you know, when there's not really deeper, we don't want to have somebody sent in, I'm having a hardware problem. And then you come back and have to say, okay, which piece of hardware is it, I want them to say I have a hardware problem, and then they select the hardware, you know, I'm having my issue with my monitor, you know, and then you're, you're digging deeper, where you have a serial number, and all that kind of information. And these are basic examples, but I want to make sure that you're focused in on understanding that we can grab this information early on, so we don't have to go and use an iterative process to get back to it. And then this is something that we all miss out on, because we're all scared of being wrong on it. And that is set expectations. You know, an SLA is a set level of expectation, and there's nothing wrong with that. But people want to know, individually what the expectation is. And so when they selected a priority, for example, on our tickets, we used to make it so they could actually change what settings, you would see that a high priority setting is, you know, one to two days, as far as an SLA, whereas a tutor, you know, a low priority setting might be two to four days. So, you know, it all depends on what's really working for you. Okay, so let's talk about getting the information to the right people. Because again, this can be unbelievably important. So, you know, so many times, you know, when people call into a helpdesk, they don't automatically realize that the person that they are dealing with, is almost like a project manager. Now they're going to handle some basic information, they're going to handle some troubleshooting. But they're almost like a project manager, because they're getting things ready to get this information in front of the person that can actually solve the problem. How many times when we call into even a simple call center, do we get transferred to somebody else? Because they're there to collect the information, get as much as they can out to you and then determine how do I route this? Where do they go to? Now, sometimes it can go directly to that team immediately. And that's really helpful. Other times, that might be a team that's more in the background, and they don't have a customer facing side to them. And so, you move the ticket, you know, over to them so that they can work live behind the scenes, and then it comes back over to you, and you contact them and say, Okay, we've now resolved the problem. Let's go ahead and give this a try and see how it works out for you. And that is fine as well. But getting it over to those right people seems to be an area where it gets difficult. And this can be a huge time sink, because now you're not in control anymore. Now, when you pass this over to another team, you know, you might have an internal SLA, your internal clock can stop ticking, because you pass it over to another team. But at the same time, the overall external SLA is still ticking away. Because as far as the customer is concerned, you're all one big team. They don't care that there's an internal side and an external side, they don't care that there's an engineering team and a NOC team. When my customers were talking to me, in my noc, they thought that I was the one that was going to solve the problem, but they didn't realize that I found a lot of problems. But I was more of a project of almost a ticket manager. I managed their ticket in their system, that we could answer it, we could solve it, we would and if not, we would pass it over to the appropriate team. And that's really a huge piece of this. So, as we mentioned, this issue can cause huge delays determining where it goes. Do you have a flowchart? Do you have a list of who's responsible for what you know where somebody comes? then and they say, hey, I'm having a network problem. And it automatically goes over to the networking team, where it automatically goes over to the server team, if it's an application issue, have you been able to successfully identify where it goes through. And I'm going to tell you right now that if you, when you pass tickets to an incorrect team, a lot of times, they don't push back, they expect that anything you put in their queue is theirs. And sometimes when it lands on their queue, and it's not theirs, they don't always reassign it back to you or back to the appropriate team, it's going to sit there. So, make sure that when you reassign a ticket, and you say, I need to pass this ticket over, that you understand why you're doing that. But you also have to have that agreement with the team, that this is the kind of ticket that I will be sending over. And you want to set up communications with all those, those secondary teams, you want to set up communication, saying, hey, I'm going to passing these types of tickets over one, two, and three, okay, when they come over to you, it is now your responsibility. Sometimes just identifying who the subject matter expert is, can take time, you know, you'll get a ticket or you're like, Man, this is a very rarely use piece of what it is we do, I don't know who's responsible for this. I know, Jeff used to do it six months ago, but he left the company to who's handling it now, you know, especially in a smaller operation, you know, you're in a smaller operation, and one person leaves and all of a sudden, there's a void of maybe four or five different areas that that person had expertise on. And maybe his workload just got divided up by five different people. So, you're gonna see that a lot as well. So just identifying who is responsible. So, it's almost like you can take that your process, your workflow process, these are the kinds of tickets that we expect to come in. And based on this, this is the team that these tickets should be going into. And it becomes almost like an upside-down tree, where it starts with a main ticket, that you have the hardware side of software side, again, I'm giving an example of the help desk here. And then you break those down further, and then you assign who is the SME for each one of those. And by providing that to your helpdesk engineers, they're going to have an understanding of where it's going to go. But more importantly, those teams are going to have an understanding as well as to where those should go. So, it kind of goes both ways, as to, you know, where we end up here. So, you want to identify that f&e early to the ticket doesn't sit in the queue untouched. And, you know, if you're having problems, this is where you got to give your helpdesk engineers a voice, you want to make sure that they have the voice. Sustainable. I don't know who this goes to. You know, we used to have a SWAT team. Oh, it was a SWAT team meeting, it was tickets that were either coming up on our SLAs or even new tickets, that didn't seem to have directions. And every week, we would meet on a SWAT team. You know, and this was for the very, very difficult tickets that were that were coming up. But we will say okay, what do we need to worry about, and these, these tickets, the meeting was every week, but the discussion that occurred on them was during the standup every day. So every day in our standup, we would say okay, somebody will say I have this ticket, I don't know who to send it to I, I sent it to Joe, and I didn't hear back from Joe, you know, I send it to Mike and Mike sends it back to me, you know, so we see that all the time as well. So, you really want to make sure you identify that. And the other piece that can be really helpful here. And something to think about is when you do have other teams that are involved, make sure that they are sharing in your SLA, make sure that either they have their own SLA for resolving tickets and or they're sharing in yours. And I mean that both ways they need to share in the issues that come in, you don't have yesterday's, but they also have to share on the victories. So, when they hit their athletes, they should be getting rewarded just like you do. Okay, and when they miss their SL A's. They should also, you know, feel those consequences as well, just like we all do. And those I'm not talking about major consequences here, but I'm saying that maybe there's a bonus pool that set up for every quarter. And when the team's hit it, they get they get their bonus and when they don’t, they miss it, they miss their bonus. So that's a real thing that we used to utilize because I needed to work with these teams. I needed them to understand the yes, all the other work you're doing is super important. Don't get me wrong. We were moving data centers and that was a huge project. During the time I was a NOC manager, but my customers and they still needed to be service bears and I remember sitting down with them explain them guys, the reason we're moving data centers is because the customers are need us to do so. However, if we move data centers, and we don't take care of our customers during that time, there's nothing to move to, the customers aren't going to be there. And they're not going to require any data center, if we've already angered them, or upset them to the point where they've left. So, we have to take care of them while we're doing this project. And I explained that I know this project is enormous. Moving to a new data center is not a small task, especially this was before the cloud. You know, we're talking 2015 2016, where the cloud was really heavily utilized. And so, moving in a data center, moving to a different data center was a huge job. But I had to sit down with them. And I also had to get buy in from leadership, that we have to make sure we're taking care of where we are now. And trust me, because I key leadership is so heavily focused on the future, I've got to get this done for the future, I've got to stay ahead of the curve. And it's literally in our DNA. When we get into IT leadership, that's where our mind goes, stay ahead of the curve, you know, making sure we're cutting edge, making sure that everything remains up. But we have to remember that as we're doing that, we have to take care of the current state as well. And so, it's important that you have that buy in asking the right follow up questions. Now, this is something that I see so often. Because, you know, we don't have all the insights. So, if you're on a phone and you're taking information, or you're reading through a ticket, the first thing that's going to happen is you're going to start making assumptions. And that's not bad. I know that people say that assumptions are really bad. But in this case, they made they're not because you're taking your expertise here, all of the information on what it is, you know, you've done in the past, and all the issues that you have seen in the past, and you are going to apply it to every new ticket you have. And that's why you're sitting in that seat. That's why you want people that are familiar with working within ticketing systems are familiar with your product. The whole idea is it when I used to go out onto a job for SolarWinds. To do an implementation of SolarWinds. The one thing that my customers loved about it is that I had seen hundreds and hundreds of SolarWinds implementations, I, you know, said so many of those different guys seen what others were doing. So, I would quickly sit down and make assumptions, though some of those assumptions are going to work out. And some of them are not. And that's okay, as well. But we want to make sure that when we do that, and we make those assumptions that we are asking the right follow up questions, A, we want to confirm our assumptions. Okay, so you're gonna make certain assumptions. And that's not a problem, but you need to confirm, you need to confirm that you're correct. Because otherwise, what happens is you make those assumptions. And then you start going down a path and that path can be incorrect. And that's, again, gonna flick up some of the time of having this open ticket, it can even lead you to bring in another team, the other team goes to work starts, so worked on it. And then you come back on Wait a minute, they weren't talking about X, they were talking about why. And so suddenly, you have you've gone down this rabbit hole that has cost you time, energy and resources from other teams, and you have nothing to show for it. So, this is an area that you really want to concentrate on and say okay, let me get the proper questions answered. So, technicians often utilize a turn off the SLA agreement clock and move the ball back to the customer site. And I see this all the time. And I've seen it, even with the most seasoned technicians, where the goal is, you know, when it's when I've changed that setting, or the ticket status to waiting for customer, my SLA clock is turned off. And you kind of get a sense of relief when you're focused on ticking anymore. And we've all had that. So, what they'll do is they'll ask a question that could be important, but probably isn't important, just to pass it off, just to buy them time so they can move on either to the next ticket. And you see this a lot. When teams are overwhelmed with the number of tickets within the amount of work they have to do. I see it all the time where people would just shut off the clock by saying I responded to the customer. And that response wasn't going to move the ticket forward in any way. It wasn't going to make an impact on the customer. problem getting resolved. And so, because of that, it leads to two things. In these two, the SLA not really being representative of how long does this taking, and be, and more importantly, it leads to a frustration with a customer that, again, maybe this person, or maybe this key doesn't understand this product as well as I need them to. And I'm relying heavily on a product, whether that is, you know, IT support, or hardware maintenance, or even, you know, mechanical maintenance. So, you might be using Service Desk for when you rely on them, and you don't have that it makes you start to look elsewhere. So, you want to make sure your technicians have the questions that they're asking are very, very clear. And they make sense that this is going to move this ticket forward. And it's worth the iteration. Because if it's not worth the iteration, you've got to find out, okay, what is it that I need to do next, to make this worthwhile, because I'm gonna put this in front of them. And it's great that the clock stops. But there's a cost and every iteration has a cost associated with it, you want to make sure that the cost of that iteration, you're gonna, you gain something, because you gain knowledge, but you actually lose a little bit, every time you do an iteration, you lose a little bit of that customer satisfaction going, man, they didn't give me what I needed. And just a little tiny bit of satisfaction, you might you may lose each time, you have to make sure that you're spending that as though it's gold, because it is gold. Okay, you want to it's like you're putting it out there and saying, Okay, I'm going to ask these questions, but I'm going to lose a little bit for asking these questions. And eventually, you're gonna run out a goal, you're gonna run out of customer satisfaction, and how that customer feels about you, your department and or your company. So, make sure that every iteration, every question you ask is going to provide you the information that you need. Okay, so obviously, after this causes more delays, and more iterations, so you're asking questions that don't really matter, you're gonna have to eventually get to the questions that do matter. And so now you've got another iteration. So even though that clock was stopped, eventually that clock is going to catch up to you, that SLA is going to catch up with you. And just because you paused it, now you've got to deal with the right, the right questions to ask. So, the clock is going to be turning again, as well as you've lost some of the customer experience, and the customer satisfaction with. So, you're actually increasing your MTTR, and you're decreasing your customer satisfaction scores. But by doing this, ask multiple questions in a follow up, I can't tell you how important this is. Go ahead and say, hey, have you done? You know, what steps have you done? If you know, have you tried this? Have you done this? Are you utilizing this, ask multiple questions, because the more information now that you've gotten the basic information that your, your form, and your dynamic forms can provide you with, now you have a chance to really dig in and find out what they want. So don't just send them an email that says, Okay, I need these diagnostic files, or I need a serial number. Start thinking to yourself, what else am I going? What other questions can I ask to get more information from them? You know, and that's a huge piece of this is to make sure that we are really asking multiple questions on every floor, on every iteration, because again, maybe you need it, and maybe you don't, but now you got it. And even more importantly, what you're gonna realize is, we all do this, we all have a list of tickets that are customers open. And maybe those questions are going to be answered in other tickets. So, make sure that even though you're dealing with ticket A, the you've gone back through the other ticket history, and this is a really important thing to do. Find out what other questions are asking, find out, did their problems get resolved? You know, I want to know, am I dealing with a customer who's satisfied with our service or dissatisfied with my service? You know, get that information as you're dealing with these customers, especially when you're on the phone with them. When you're on the phone with them. It's even more important because the frustrations tend to come out more on the phone. They're both though they're more willing to get angry in the email, but you'll hear the frustrations from them on the phone. And then finally, and this is interesting, because we don't do this enough. I don't think because we're worried about leading them down to the wrong area but try to anticipate their answers and ask additional questions based on what those answers may be. So, thanks if they send you an email Now, I'm going again, I'm going to use a very simple ticket of my monitors not working. You know, instead of sending them the is the light on the front of the monitor red. You can say to them, is the light on the front of the monitor red? Or is it off? If it's off? Have you double check to make sure it's plugged in? You know, and that's, again, a very basic example. But take them down, okay? If it's not like this, what's the next troubleshooting step that they can perform? You know, make sure you're asking him, what have you tried already? What have you already done to attempt to fix this problem? You know, because the one thing I don't want to do is start sending them instructions on how to solve a problem. And they come back, and they go, Yeah, I already did that. I tried that three times. You know, it didn't work. I don't want to go down that. So, think about what questions to ask. But more importantly, think about what their answer is going to be. And their answer is going to go in a certain direction, see if you can follow it up with an additional question. Right? In the single iteration, you're saving yourself an iteration, which means you're taking again, hours, slash days off of your SLA, depending on what your SLA standards are. That can be a huge time saver for you. People that utilize this technique. These are the engineers, these are your, your ticket engineers, and your helpdesk engineers that you absolutely love. Because they get these are the guys that close the tickets all the time. All right, we're gonna move on to here to provide the correct troubleshooting steps. And everybody says, of course, you know, DHA. And yeah, you're right is, is one of those moments where like, of course, we're going to provide, but I can't tell you how many times I've seen engineers provide troubleshooting steps that were incomplete, that weren't the correct process, that we're missing things that had gaps that weren't easily understood. You know, I used to say to people, I don't, you don't, you cannot expect the other person on the other end of the line, whether it's email, or it is phone, to have the knowledge that you have to have the experience you have, and to be honest, to have the capability to do what it is you're asking them to. So, when you're, you know, providing troubleshooting steps, you need to keep that in mind. You know, we all tend that we talk to our colleagues every day. And I can sit down with my colleagues, and I can start spitting out alphabet soup all day long. And they'll know exactly what I'm talking about. You know, and then you got to remind yourself that you don't always get it. I remember when I when I first got it got involved. With Monalytic, we did a lot of government work. And I had never done government work before I started with Monalytic. And a lot of DoD work. And all of a sudden, I had people spitting out alphabet soup at me, you know, with all of these acronyms from the government and the military that I had never heard of, you know, and so I had to slow them down. And I remember, I spent half my days, you know, the first couple of months of my job really googling acronyms and typing in, you know, what is this? What is this and learning that way. But they all just assumed that because I was working there, that I had that information, don't make the assumption that the people on the other side of that phone or that email, have that knowledge base. So, make sure that whatever instructions you're giving them to troubleshoot the problem are very clear. Let's take a look at are providing the correct troubleshooting steps now. So, the first thing is, are the troubleshooting steps up to date? And do they provide enough detail, and this is where we get back to, hey, you're not necessarily dealing with an expert, you're not dealing, you know, with somebody who knows your product or knows what they're doing as well as you do. Even if they are the SME for their company, they may be calling up and say, hey, I have an SME for will save for SolarWinds. I can't assume that they have as much knowledge as the SolarWinds support person, because they don't. They don't have that insight information. So, you want to make sure that whatever information I'm providing to them, they can follow any query concise, step by step process, and the detail is there, and that they're up to date. Let's be honest, you know, things change, and they change quickly these days. You know, companies are constantly pushing out new versions. You go to Google a problem. And suddenly, you're shown four different ways of solving and you got to figure out you know, which one is dealing with the version of the software that I'm working with? So, make sure that you're looking at, you know, are these troubleshooting steps up to date? And then let the customer know what you feel like the chances are for success. To be honest, this is really weird. You know, wait a minute, I don't need a guy to my customer and tell him that I can a solve your problem, no problem. You know, I can say to them, okay, this is a difficult question that you've asked, I'm going to need to bring in some assistance, and I'm going to get you an answer. The fact that you don't have the answer off the bat shouldn't be a problem. We are not a bunch of Brainiacs. As we're sitting in the chair, not necessarily because we have the answer. It's because we know how to get the answer. Again, it comes back to that project manager, you know, but people expect us to have the answer, we know that. But if we can prove to them that we can get the answer, they will be just as happy as long as we do it in a timely fashion. And we give them what they need to look like rock stars, I always say that, you know, my job in the NOC was to make everybody else look good. You know, I want to make my customers who are the SMEs, for the product look like a rock star, because they look like a rock star than I look like a rock star. You know? So, it's all about making sure that, you know you've shared with them. Okay, this is a difficult question. And you don't have a problem saying? Well, I'm not sure I know the answer that let me get you the correct information. I speak to customers every day, on the phone. You know, when I'm when I'm helping out with the SolarWinds Orion products or service desk when I see them? I'm not sure I had the answer that let me get it for you until we can get it for them, you know, in a, you know, an hour or two. But I want to make sure that what I'm providing them is correct. I want to be honest with them, when it's a difficult ask that it may take a little bit longer. Okay, did you provide steps to back out the change, I always send this with the steps to make the change, I always send the steps to back out the chain. There's nothing more frustrating than somebody doing something on the network. It doesn't do what they anticipated it to do as far as solving their problem. And now they're concerned that it may do something else. And they've got to go back through the process, why actually find out a reverse process along with it that gives them how you make the change. This is how you got retained out is two separate documents, I want them to be aware of it, I want them to know that we are aware that sometimes she just needs to be backed out. Okay, it will provide them with a lot more comfort in your skill set. Because you're thinking, here's what you're going to change. And if for whatever reason, something goes awry, here's how you're going to put it back to the way it was. Because the last thing they want to do is come back from a snapshot or from that from backup or something like that, especially on a complex change. You want to make sure that all of this makes perfect sense to them as far as how they should be moving next. And then finally, does the customer need to backup their data? First? Is there a maintenance window? by you asking these questions? You know, if somebody says to you, hey, you know, where we're calling, because we're having problems accessing our SQL database, you know, whatever it is, or program can access the database as well. And you say to them, here is a process that you're going to run to solve your problem. Okay, immediately, any engineer is going to look at you. And they're going to say, well, wait a minute, how is this going to change the database, and isn't going to bring down the product. So, this is where you want to be proactive to them and say, here's the changes that you need your, it's probably going to take you an hour to an hour and a half. And it's going to bring in cause an outage for an hour, an hour, hour and a half. So, you're going to want to have achieved maintenance window to let them know that they need to let their customers and their users be aware that there's going to be an outage here while we fix this issue. There's nothing wrong with it. Be proactive about this. So many times, people send this information over. And what happens is the engineer gets it. And they come into they walk into their manager's office, they go hey, I got the answer. I got the answer. We can do this. And our manager looks at this. He goes, wait a minute, man, this, this looks complex. And it looks like it says here I got to stop services. And they're gonna ask a question by empowering them to walk into the office and go, here's the answer to our question. We need a one-hour maintenance window according to the vendor. And, you know, here's, we got to get a backup of our data beforehand. You know, let's start going to the cab team or the change advisory board or whatever means you utilize to set this up. Again, you've now empowered your customer to make intelligent decisions on how do I move this process forward. And by doing that, you're also cutting down your iteration to them calling you back up and going, hey, yeah, my boss has told me that they think this is going to bring down the product. And they're worried that we won't have a good backup, you've saved an iteration again, it's still gonna sit and waiting for the customer. And hopefully, the next call back you get is from the customer saying it was successful. Thank you go ahead and close the tickets. Well, really appreciate everybody taking the time today with us. If you have further questions, please reach out to us. We're always willing to have conversations with you regarding service desk, how you can get it implemented, how we can get it to work better. We've got a bunch of people that have done exactly what I've done. For experience, we understand how do we get those tickets closed? How do we make sure we're not missing things? And most importantly, how do we help you guys increase the customer and the user satisfaction, so feel free to reach out to us? We're here for you for that. And really appreciate everybody's time today. Thank you very much.
Corey Baumgartner
Thanks for listening. If you'd like more information on how Carahsoft or SolarWinds can assist your organization, please visit www.carahsoft.com or email us at solarwinds@carahsoft.com. Thanks again for listening and have a great day.