If It's Not in the Ticket, It Didn't Happen
IT admins, help desk, and support professionals are not only judged by their ability to solve IT issues, but also by the time it takes them to do so. If not armed with all the details on the front-end of their troubleshooting process, they could waste valuable time in the hunt for intel to make informed decisions. In this THWACKcamp session, we discuss the meaning behind the saying, "If it's not in the ticket, it didn't happen," and provide a variety of best practices to streamline the help desk request process and lower mean time to resolution (MTTR) for IT issues big and small.
Hello, and welcome to this session of THWACKcamp: If it's not in the ticket, it didn't happen. My name is Josh Berman, part of the product team here at SolarWinds. I'm joined here today by Kevin Sparenberg, and Bryan Zimmerman. Guys, thanks for joining me today.
Oh, thanks for having us.
Happy to be here.
Awesome! If it's not in the ticket, it didn't happen. If you've ever worked in support, chances are you're either tired of hearing that phrase, or tired of saying it. The fact is that every support organization relies on documenting everything that happens for a variety of reasons. So, why is it so hard? Well, I've invited Kevin and Bryan here. Two guys that have spent considerable time in the trenches of support to talk through their thoughts on this subject, and glean from them any advice we can to improve the situation. I actually credit these two individuals with naming this session so, what better way to kick things off than to have them tell us a bit about their individual backgrounds, and provide some insight into what this phrase, this mantra means to them. Kevin, why don't we start with you?
Sure, so, I'm Kevin Sparenberg. I'm a Product Manager here at SolarWinds. I have spent time in the IT trenches. I started in a help desk position, went to help desk team lead, then went over and transitioned to internal. So, I was working on networking and systems administration, before finally making the leap here to SolarWinds.
Great. Bryan, why don't you tell us a bit about your background?
Yeah, sure thing. So, I'm a Product Manager as well, responsible to the MSP Manager Solution, which is the PSA help desk solution in the SolarWinds MSP side of the business. Before that, I managed the support department at N-able Technologies.
Oh, yeah. And just to cut you off there for a quick second, N-able was acquired by SolarWinds a couple years back.
Yeah, we joined the family a few years back, and I've been a really proud member of the SolarWinds family since then. Great things since and great things to come. So, before that I worked at Dell in a lot of different capacities from trainer to transition queue, to team lead, to floor walker. And of course, the agent on the phone which is, as you said, in the trenches.
So, I definitely have heard this sentence many times and have said it thousands of times since then.
It's one of those things that comes up, especially if you get a bad ticket. You'll get a ticket, look at it and say, "This is not what I need." And then you talk to the person and they say, "Oh, well, such and such said this, that or the other." That's great. It's not in the ticket, therefore it didn't happen.
Great. So what's the purpose of documenting this situation on the front end of the support process? That's something I'm just curious about, given the subject.
Well, it depends on where you actually fall in the IT support structure. But if you're a help desk technician, the most important thing is to capture the information necessary. So that when you do, if you must escalate this issue out, you can actually take care of it as that next step in the line. If you don't have the right information and frequently that will happen, especially in new help desks, or ones that have transitioned to new solutions, you'll actually run into problems where you don't have the information you need to actually do your job. And since the help desk is basically the front end for IT support in whole, it's really important that they capture as much as possible, and hand it off to the teams necessary.
Yeah, I think we'll get into some of that a little bit more here in a second. Did you have any thoughts on that as well, Bryan?
Yeah, for sure. So think of it like this: every interaction point that a technician has with a customer is an opportunity to resolve the problem. In a large organization with complex problems, it's actually very difficult to resolve the issue on that first resolution. So, everybody's got to make a meaningful end road towards the end goal at each stage. If you're not documenting what you did, well, it's like it didn't happen. And you're not taking advantage of that opportunity and moving the ball forward. And that just creates unnecessary ping-pongs and bad support experiences.
Yeah, so there's definitely a lot to cover on this subject. But actually, I want to take a moment to talk about that first part in the process, the part when a ticket comes in, and show some examples of some bad tickets. Speaking of that, the source of this, Chronicles of George-- tell us a little bit about that, Kevin.
Okay, so, when I was on help desk with my last company, we got some bad tickets. Every team lead does. You just kind of deal with it. You go back to the technician and say, "We're going to need more. We're going to need a little bit better." Turns out one of the guys there turned me on to this webpage for the Chronicles of George. And it's a list of hundreds and hundreds of poorly done tickets with some comments back and forth from the community. Some of them are absolutely hysterical. Some of them, unfortunately, hit a little too close to home, because I saw tickets like these, and not being able to really move forward. Basically, it was the guy who turned into a roadblock that if it was in my organization, and George worked for me, George would not have the right information. That information would go to the next team. The next team would say, "It's not in the ticket. I don't have enough information. So kick it back to George and ask him to get more information." And that just changes the entire process and makes it so much longer. You mentioned ping ponging; number one key whenever you have problems like this. So, that's where the Chronicles of George kind of dug in, and became part of my psyche after that.
Yeah, I think the team, as you described it, kind of looked to those tickets as a means of consoling their issues that they had, right?
Yeah, there's actually two parts to it. Number one, it's a list of things not to do. Don't ever, ever, ever do this kind of thing. And I think we can all agree that these tickets are not ones you want to do. But, the flip side of that was help desk typically can be a thankless job, especially if you're the first person on the phone. People are calling you. They're already having themselves a bad day. So, being able to actually say, "Oh. Hey, someone else was in a similar situation. I don't feel so bad, I'm not isolated," helped keep morale up a couple times. Especially when we saw a new one posted, we'd immediately just send it around to the team and be like found another great one, don't do this, but laugh.
So, if you've never heard this from other colleagues in the industry, you're not the only ones who have had to deal with this before. And we're trying to, in this session, try to help that from not happening to as many organizations as possible.
Yeah. So let's jump in and take a look at this. And for this, I want to say that the person that's actually submitting these tickets, he was the first line in the process of support, right?
Yeah. George wasn't the person with the issue; he was the one who took the first call. He was the first touch.
Yeah, and so with this, you're going to see some examples of bad spelling, bad punctuation, all of that good stuff, but it's the essence of the tickets that we want to talk about as well. So, let me pull these up. [Buzzer sound] [Laughing] So I'll play as George. For instance: "Blank is havening problems with getting..." Wait. "Blank is havening problems with getting on to network, she says she gets nocked of the network." So, that's just one example of some pretty bad language, some bad spelling, but I think the important point to note is that the urgency is marked as urgent. The priority is urgent. That's kind of concerning to me. What do you feel?
Yeah, so there's a lot here. So, you're George, right?
Yeah, I'm playing George. Don't hurt me.
So, there's a bunch here. We'll skip over the obvious spelling and grammar because that's obvious from the sentence, but also that's not really substantive in terms of interfering with the flow. What's interfering with the flow is the lack of substance and lack of content. So, urgency and priority-- what you've done here, George, is the L2 or L3 who gets this call, he's not likely to actually prioritize that properly. I almost guarantee that you set the expectations with the customer is wrong. If you just said well this is urgent--priority, urgent--what does that actually mean? When will they actually get help? Very likely, what you expect, and what the customer expects is going to be misaligned with the L2 technician who gets this wonderful case. The next thing is you've missed the opportunity to actually move the problem forward. So, "havening problems with getting on the network, "gets knocked out of the network" doesn't really tell me anything. Am I wireless? Am I wired in? Which network? What building? What's the IP? Do I lose the IP? Is it a browser problem? Just defining what it is the user is experiencing is really the first step to being able to resolve the problem. Here, I actually don't know what the problem is. All I know is you might need some spelling lessons, and there's a problem with the network.
And we don't even have the computer name. As simple as that is, you want to make sure you have something like that because you mentioned the IP and the DNS, and making sure you can resolve it, and what office. Sometimes a computer name can actually give you hints into all of that depending on how your naming scheme is, and how your IP addressing schemes are. So, sometimes just a little bit of information can help us process this forward.
We're only assuming that we know who she is, but maybe we don't.
No, that is true. If you don't collect that information on the front end then you're at a lost and you're going to have to go back to poor old George to get some answers, I guess.
Yeah, and urgent is always something that causes me a problem. Because when I went through and we started architecting help desk solutions at one of my previous jobs, we actually had to create a second priority. One was the end users priority, how it felt to them, how their experience was. And then there was the actual IT scope of it. So, for this one it would have an actual, technical priority of medium or low, because this person obviously can't work. But then when you talk about how it's affecting them as an individual, it's super urgent-- you need to get that taken care of. So urgent's kind of okay, but you've got to make sure you scope it correctly.
Yeah, one of your main jobs as support or service provider technician is to manage that customer expectation, and we can do a whole topic on that, I'm sure. There might actually be one, who knows. By saying something like 'urgent,' you're not actually setting the expectation of this is our priority one, and here's the SLA attached to that. All you're doing is describing with an adjective and what I've learned is when you don't set expectations, customers come up with their own. And their version of reality is often a lot more optimistic than our version of reality will be.
So let's move one and talk about the next ticket in the queue here. [Blooper sound] [Laughing] So, again, 'havening,' another fun saying. "Blank is havening problems with her internet opening up, "it freezes up every time she opens her internet."
Please, let me start on this one?
Yeah, go ahead.
Okay, so here's the thing. "The internet opening up." Number one, we all know the internet doesn't exist on anyone's laptop or desktop. So, let's just go ahead and say this person means an internet browser-- may be a safe assumption, hopefully. Then, you have the problem with it doesn't tell you which browser, because most machines come with one, two, or three browsers, depending on your organization stuff. It doesn't say if they're going to a specific page. It doesn't say if it's on initial launch. And when it says, "freezes ..." 'Freezes' can mean a lot of different things. There is the full lock up which means your mouse moves and nothing else does. No other applications. Then, you've got the application itself is frozen, or it's frozen--the desktop. A horrible example of this is the blue screen of death, or the unhappy Mac or the Linux-- what is it a red screen, I think now? So those are the kinds of things that could be interpreted from this ticket, but again, we don't have enough information to actually move this forward. I see this one and from way too many years of experience with bad tickets, I think this is a client issue, and I need to send someone out to that client to do a quick check on it to make sure it's something that's not ... That it's systematic on that particular machine.
Fair enough. I got another one in queue if you guys want to take a look.
You're feeling up to it?
Yeah, go ahead George.
Let's give it another try. Let's see what George has for me. "Call me." [Slow trumpet sound] [Laughing] "Call me." What do you guys think about that?
No, no, no.
I'm going to have to get you in the corner for this.
I'm just going to walk off.
No, no, no, come on back. This is like the worst possible ticket, and I'm sure you've gotten one like it. Now, sometimes these are necessary depending on who it is. But the fact that there's no scope here, that's what bothers me. I can say to someone, "Look, I've got a document to get out of the door. I need to make sure it's available in the next 24 minutes because it's got to be submitted to such and such, and blah, blah, blah." It's all great. "So, I need you to call me because we need to find an alternate way to do this." Brilliant. "Call me" doesn't tell me anything. Especially when you look at the way it's prioritized, the case type of 'problem.' What is that? Does anyone understand what 'problem' is? 'Problem' is so generic.
It's not a solution; it's a problem.
Obviously. So, the beauty of this one that I love is the source is the phone. So, they've already called in, left a message of "call me," and now have to sit and wait until someone actually picks up the phone and calls them. And based on your SLAs and how you actually work your escalation process, this could be five minutes-- could be three hours-- could be twenty-four hours.
The other thing is if I look back on my history, anytime I've actually gotten a case with this kind of verbiage from a customer, it's normally because they're really frustrated. And likely, there's a long running issue and a support experience that they've been unhappy with. This case isn't going to help that.
The reality is they have any expectation. They want someone of some level of seniority, or responsibility, to call them about a problem in some amount of time. Now, if I were to guess, I would say they want someone in management or a senior tech to call them immediately about their previous case. And that would all be awesome to be in here, but without that detail, all you've got is a missed expectation waiting to happen. And this is going to perpetuate what likely is a frustrated customer already. So, again, this is a touch point, an opportunity to repair a relationship that George has squandered.
Yeah, because you can actually take "Call me" and add two words, "regarding ticket number," and put the other ticket number in there. And if that one is documented well, you might have enough to at least make that touch.
We had to make a lot of assumptions regardless of this situation, but we touch on a lot of great points. And Chronicles of George was a good leading point for that. But one thing that I want to talk about is the task of documentation. How is that viewed by technicians? Maybe that is something you can take, Bryan.
Yeah, for sure. The reality is that technicians love solving problems. We're all in this because we enjoy technology, but also, more than that, we enjoy helping people. And a problem is a person waiting to be helped. So, people on the help desk, people in all walks of technician life wants to solve problems. They want to help people. They don't view documenting what they did to be part of that solution. They want to move on to the next problem to solve. Their mind is reading for the next puzzle. They want the next person to help. They don't want to spend an inordinate amount of time documenting what they did because that doesn't matter. The problem is solved; it's fine. The reality is you don't know if the problem is solved, it could come back. Or perhaps you solved a problem that nobody else on your floor could, and by documenting that, you've now solved a hundred problems in the future that you never even would've known about. People need knowledge, they need documentation, and they need that brought forward. So, it is really onto yourself to make sure that that's being done. But people don't necessarily have that as an intrinsic value. And the last piece of that is there is a compliance and liability part of this sometimes. Looking as an example, if you're an MSP who is supporting customers in the health field, HIPAA compliance requires that you have clear documentation of chain of custody of any personal, identifiable information. So the issue of if you don't document everything that was done, is you may actually have a gap in that chain which actually has real consequences. So, it's not only just a matter of better service, sometimes it's a matter of contractual obligations or even legal problems.
Sorry to interrupt, but the help desk I came from was actually outsourced originally. So I actually worked for a different company and was placed at the organization where I worked. So, similarly, we had specific SLAs as help desk personnel. Now, our SLAs were very billing-based. So, we got X number of tickets per month, anything above that then we charged-- I forget how much it was, but it was like a group deal-- for the first fifty tickets, you get charged additional dollars. And for the next hundred, you got charged additional dollars. So, keeping track of that information and making sure that the tickets actually have validity-- so if you have to go after the company and say we need more money for this because we've provided this level of service, you kind of need that. Because if every ticket is "call me," and the response, the work log is "closed." Save. Then they are going to fight you on those over and over again.
Yeah, that's actually really common in the MSP space or the Service Provider space in a larger sense. In the MSP world, when you have any kind of overage--if your customers are a monthly retainer contract or a block hours contract, anything that actually can have an overage rate applied--they actually, when it goes into overage hours, ask for detailed bills--sometimes down to the level of every single time entry, every single thing performed--because they're going to scrutinize that and make sure that, "Actually I am being charged fairly or not." So that ticket is not only useful for troubleshooting, but it's a record of where they spent their money. And people really care where they spend their money.
So I want to rope things back in a little bit. One thing that I wanted to touch on is that sometimes technicians view the documentation piece as a chore, as a task, almost as a barrier to their own work. Is that the mentality that they should have?
No, not at all.
It's not the mentality they should have. Unfortunately, it is the mentality that a lot of them go into the job with. And it's no fault of theirs. And maybe this is just my experience with help desk technicians, but they were people who were technology clever. So, they were the ones that fixed all their family's computers. They were the ones that fixed their own. Maybe they had two of their own, and they were doing very specific things. That's kind of the help desk first step, or at least that's been my history. So that's all well and good. But when you do that, how often do you document, "Mom ran antivirus, updated that file, did these six things. And here's your record mom. No, don't worry about paying me right now, but here's a record of everything you did." That's where they come from. So, when they get a job, unfortunately, mentally, they're going, "I'm just going to do the same thing. Maybe I'm starting it in another system..." And depending on the difficulty of the help desk solution, and the architecture of it, you can actually have problems where it takes them so long to get a ticket started that there's dead air on the phone--or there's a lag time between the time where they just write the summary and be able to put the information about it. So you need to make sure that you have all the information laid out in the best possible way for people in advance, so they can actually start the work. Now, breaking them into that habit is tough. And that's where 'if it's not on the ticket, it didn't happen' really comes in.
For sure. So, it is a cultural shift to take technicians away from "I'm here to solve problems" to "I'm here to solve problems and document what I did for future tickets, for liability reasons--" For all the reasons that we said. It's a cultural shift that really has to be hammered into the technician's workflow. The problem happens when a technician will spend 100% of their focus resolving an issue and have to go back to document it, it's actually really difficult. They're going to get something wrong. And that's overhead that isn't necessarily providing value because they feel it's resolved. Now, we all know that they don't know that-- they can't know that-- it could come back, but they do feel it's resolved. So, the behavior to really get into people's minds is document things while you're doing it. You need a solution that actually makes that easy to do. Make sure there's no barriers to starting a ticket, no barriers to starting a documentation, and that your workflow throughout is going to be conducive to making those documents and those notes as you're resolving the issue.
That's great. So, I want to transition things over here a bit, and talk a little bit about the devil that's in the details-- the minimums that are required for tickets. This is something I want to transition over to you, Kevin, to talk a bit about.
Sure. So the real thing with the devil in the details is that there is a minimum bar for ticket detail. You've got to realize that you need to know who submitted the ticket, what the issue is, and what they first line technician has done to try to remedy the situation; because that can really help you when you're moving that ticket forward. Now, either as an additional advance portion of that, where they go through and you gather additional machine info, the properties of the applications, maybe some specifics if it's a custom app, then you can get a little more information. You can also, hopefully, do some support with some type of remote support solution and there's all kinds of solutions you can use for that. But you have to capture this information. Because let's say I'm that first line technician, and I'm putting information in and I'm trying to fix the problem, and I can't. It's just outside my wheelhouse; it's something I'm not familiar with. So then, I have to take that and send it over to someone else. The last thing I want is someone to punt that ticket back to me. Because if they punt it back to me, that mean time to resolution just ticked up. Now, that can be a short tick or it can be a very large one, and that's where you really run into problems, especially when people are very lax about documenting the tickets.
That's good information. Something that I also wanted to point out, we have someone here representing the MSP side of the house and that's you, Bryan. I don't know if this really suits the situation for you guys. Can you explain that?
It's a little different. The biggest difference between MSPs and your traditional organizations is that MSPs are dealing, almost exclusively, directly to that end user. There's no one extracting the information; there's no internal IT, for the most part, that's filtering out the issues before they get to the MSP's technician. So, often what you get is stuff right from the end user. Now, a lot of MSPs have a level one, two, three model; so it is still important for that level one to make sure that they document everything for the level two. But those people work in a very tight knit group, constantly working together to a common goal, so that's not normally the issue. The issue is getting the info from that end user. So, really the strategy here is to have tools. If your help desk tool is basically an ITSM-- so it has asset management and system management built into that-- to be able to take data automatically, as much as you can, without having to ask the end user or count on the end user's veracity of their information. Their version does not always match reality. So, it's good to be able to get that information directly from the system. And then secondly is remote tools to be able to pull the information you need when you need it, so that all of that is done when it gets escalated to the technician. So it's really the same goal, it's just a little bit different. There's more heavy lifting by that L1 technician and the customer can be counted on for less of the work.
That makes a lot of sense especially given the divergence between the two kind of models. Now I came from inside, so we kept going back to that first technician and being like, "No, no, no. You need to get as much in there as possible." Because our goal was first call resolution. That was always the goal and was one of the metrics that, internally, we tracked. Someone called--first technician was able to resolve it. Boom. That’s one mark in the first call resolution. Now, we were having a discussion and you said that's not quite as critical in a MSP?
What's critical in the MSP is actually the SLA. So contrary to what some people might be thinking, it's actually pretty common for MSPs to have an SLA to resolution. For those who are working on more of a software support help desk or an enterprise IT help desk, that's normally a concept that we don't have. Because really complex problems you can't guarantee a resolution. But a lot of MSPs will have it in the SLA agreement that a critical level problem we're going to resolve within eight hours. And it is understood that sometimes things will fall out of that if they're dependent on parts, or dependent on the customer. They're basically on hold, the SLA is paused. But the idea of having a “we're going to resolve issues of this category and this severity in this time frame” is firmly ingrained within MSP SLAs. So that L1 technician, if it goes to the L2, that ping-pong doesn't happen to the same extent because you're going to miss that SLA. So really, that L2 will have to deal with it. But you would have a better chance of hitting your SLAs if everyone was doing their part equally. So, it's still important to do that, it's just going to manifest itself differently.
So we're scratching the surface on something that I think we should illustrate with a quick little demonstration. It's the transition of information across all streams of the organization, or the support organization. The way I'd like to do that is by playing a quick game of telephone. So, why don't you tell me something in my ear, and I'll pass it along. [Whispering]
I heard the internet isn't working purple monkey dishwasher.
Yeah, so, that sounds about right. I think the point that we're trying to make here is that sometimes information can get lost and that just reiterates the point that there is a need for documentation--whether you're collecting a bunch of information on the front end when you're supporting an internal team or whether you're collecting the bare essentials and using automation to figure out all the other information that's needed on the MSP side of the house. We're gathering that information, we're passing it along into each person that's involved in that support process. And helping to bring down--lower that mean time to resolution, which is so critical.
So don't let your help desk become a game of telephone.
And don't let the rest of your IT do it either.
So how have you guys dealt with that situation in the past? Surely, it's happened before--where you've encountered this before. Not always are support issues going to come in via ticket, that's through your help desk solution. You might be fielding requests over a phone call or chat, or other sources.
Yeah, and for the company I came from, we handled it a couple of different ways. Now, when I first went in there, there were actually, of all the offices, there was a couple of small help desks around the organization. Normally, two to three people that answered the phones. Then there was one or two people to walk around and actually do printer swaps, pulling out laptops, changing desktops, worrying about hardware problems. And then there was the Level 3 teams, which basically took care of the organization as a whole. The networking systems, active directory, those kinds of things--the public web. That worked really well when you had problems in those small offices. They went to a consolidated help desk, which I was on and hired on to. And the consolidated help desk, basically we had to teach all of the end users that they need to change the way they're doing things. Because normally they would just contact Joe. Joe has been the guy they've been working with for years and they just call Joe's number. No, now you'll have to call the centralized desk. One of the biggest troubles that I actually had there-- I was on one of the implementation teams-- was taking the information from these various support organizations-- because really that's what it was when it was segmented like that-- take out of those solutions and actually bring them into a knowledge base. Now, there are tools nowadays that are a whole lot easier for doing that. But what I've found repeatedly was Joe, the help desk technician in one of the small offices, got a call from George, poor George. So George calls Joe; Joe writes down virtually nothing. It's like, "I need you at my desk" kind of ticket. Similar to the "call me." and then they go up and they fix the problem and they just say closed. And that is completely not helpful when you need to go to a centralized solution, or when you actually farm that stuff out to an MSP. Let's say the organization I came from said, "You know what? The help desk here is okay, but it's not everything we really want. So we want to actually farm this out to an MSP and have them do the internal escalations." Which is a completely viable solution. But if you don't provide people with the right information, good history ... I hate to say it this way, but everyone has the 'problem caller,' that one person that takes over your help desk queue. If you don't actually have that information to hand off to whatever team-- and whether that's an internal team, an external team, whatever-- if you don't have that information to hand off, you're basically hamstringing yourself. Your organization is going to suffer. And support as a whole, and even worse, the appearance of support from the end user community, is going to suffer.
There's a lot of things that you said there that I want to touch on. Some great comments. So first of all, the idea of the problem customer, the problem user, that's really important. In the MSP space, for example, it's actually quite common for an MSP to actually, during their regular, quarterly business reviews. They call that vCIO services, where you'll look at the trends in terms of your help desk and calls. And if there's one person or a group of people that are actually spending more of that customer's money, that customer's work contract with the MSP, a disproportionate amount that is, more than the general population, then the MSP will actually recommend, "Hey, I think we should do some project work "to educate these people." Or, "Let's try to proactively resolve these things." So, if you don't have the documentation to be able to find those proactive touchpoints, you're not feeding into your project revenue stream, and secondly, you're not actually going to help the customer have lower IT costs going forward. And that's the whole proactive model--is to try and make sure that you're not only addressing the calls, but setting them up for success in the long term. The other thing you mentioned that was really important was it's not just a matter of resolution; it's also a matter of customer experience. And if I'm a customer who's called in and I've spoken to the L1 and given them a bunch of information, and that wasn't documented, then when I speak to the L2 they're going to ask the same questions because they're important questions to ask. So, we're talking about not the-- actually I only assumed that George is not asking the right questions, but maybe he is. So let's assume George is asking the right questions, and just not writing them down. Then when it gets to that Level 2 technician, that customer is thinking, "I just said that to the last guy. Why did I have to talk to that guy first? Why can't I just go to you?" Or, "Why do I have to answer this again? Stop wasting my time." And now you're actually causing a customer satisfaction issue, which both on the help desk and the MSP side, that's super important. On the MSP side, the customer relationship is the most important thing. That's the most palatable, physical thing that is offered to that client. And on the help desk side of things, the ability to have good customer satisfaction ratings, that's a differentiator for most businesses, being able to continue to work. So, it's very important on all sides of the coin.
Yeah, and it doesn't even matter whether your customers are technically the internal people who work for your organization-- that's where I came from-- or whether your customers are pseudo-outsourced-- the MSP side-- where basically you provide them the information and the procedures and policies to actually work with that help desk solution. It doesn't matter who they are. They really all need the same kind of information. And getting that information into the person's right hands, in a reasonable amount of time, is basically what the SLAs are built around.
So, we've touched a bit on the structure of these teams, but we haven't really laid it out for anybody yet. So I think I want to take a look at what some of these models are that different parts of the business might live by when running their support.
So, here we have the support issue response. A couple of different models that you guys have helped me prepare to talk about this subject. Again, I imagine this is going to go back to the differences between supporting internal teams versus external teams, versus that whole MSP side of the house.
Well, it can. See, that's just it. You have to determine on which one of these models you really want to run with. Now, we got them broken up in these simple ways where we have a linear one, where the last touch contacts the end user. Now, that normally means things get resolved quicker, but that also means that someone at a higher tier--if we keep using the L1, L2, L3-- someone in that L3 level might be contacting the end user. Now, if that end-user said, "Well, I had a problem with email," that means the next time they have a problem with email, they might try to contact that L3 directly and short-circuit the process. So, linear is a way that a lot of systems start. Theoretically, anyone can solve the problem, but it exposes the higher tiers. The other option is something like a cradle-to-grave, or what you call a first touch. And that's when the person who first takes the call, escalates it, goes through the entire process, and then the ticket gets kicked back to them so they can actually close it. This is really good for customer relationships because it does a couple of things. Number one, the person you first talked to is the one who solves your issue. So, there's a really good satisfaction with that. That this guy took care of me start to finish. The other part of that is it does protect those higher tiers and prevent them from getting derailed in any of their projects by looking at a ticket that maybe isn't really their requirements. So, these I've kind of worked with a couple of places. These are the most popular ones I've seen. I've actually run... The company I came from, we started off linear because we had no choice-- because we absorbed a whole bunch of small help desks-- but then we wanted to go cradle-to-grave, and the transition between the two can actually be really difficult. Now, I haven't worked on the MSP side, are these both still valid?
Yeah, on the MSP side it really depends on the verticals you service, the size of your organization. If you're a small, one man MSP, you're going to be cradle-to-grave by necessity. As you get larger, when you service specific verticals, you might actually choose a model depending on what works for you. Linear is certainly much more common. I've also worked on help desks and support organizations that use a cradle-to-grave model. And one of the things that you didn't mention that is really neat about that model is that it inspires a higher degree of ownership of that L1 tech. If that L1 tech doesn't document things properly, troubleshoot things properly, in the linear model they may not always get the feedback and really feel the result of what they did in that first contact. In a cradle-to-grave, they're the first and the last contact. And so, they feel the effect of everything they do and everything everybody else does. So, it's a very different model from an ownership perspective. But I think the important thing is that you pick the model that matches your needs and your customer's specific needs.
Speaking from the perspective of the end user because I haven't worked on a support team before, but I actually have submitted quite a few tickets in my time here at SolarWinds. We actually use one of the two help desk solutions that are offered by our company, and use that internally. So, when I have submitted support tickets, I've experienced both sides of this. So, sometimes I'll have somebody that initiated the response and helped me resolve the ticket, and responded to me to let me know that, "Hey, all is clear and you should be back up and running." And then on the other hand, they've had to escalate things, clearly, and someone else would circle back up with me later on to say, "Hey, your problem has been resolved. You should check things out now."
Yeah, and this doesn't have to be an all or nothing. This can also be broken up by team. Certain teams really need to touch with the end user on every stage of the troubleshooting. Some don't need that. If someone says, "Hey, an email domain is blocked," and I'm the Exchange administrator, I'll be like, "Okay it's fixed. Kick it back to the first guy, have him call." But if it's something that you have to go through multiple tiers of support and ask a whole bunch of questions, sometimes you're going to get stuck in the linear. We actually tried it in a couple of different ways. Like I said, we were trying to go cradle-to-grave, but there were just some instances where it just didn't work.
It's interesting that linear remains the most popular system. Your experience is that cradle-to-grave was more the utopia for you.
Yes, it's actually kind of funny. Because we started in a linear one and our ideal was to get to a cradle-to-grave model. You don't have to do that universally. It doesn't have to be every single team. We had some teams that actually had a lot of back and forth with the end user to troubleshoot problems, and because of that, they had to actually touch it every single step of the way. So the person was immediately dissolved of that illusion that a single person resolved it for them. So, for those teams, linear worked perfectly. But if someone kicks something up, goes immediately to a third level team, like a firewall change-- just open a port or something like that-- that can go back to the original technician to actually close the circle with them.
So, we touched a little bit on this topic before in our quick little analogy demonstration with the telephone game, but where can communication break down?
Pretty much at any stage where it hands from one brain to another is an opportunity for break down. The idea of documentation is that it doesn't have human error associated with it. Those are words written down. They are in black and white, so to speak. Even though it's bits on a machine, it's the same idea of having it in black and white. So, anytime that you're actually trying to take intelligence and knowledge from one person to another, that's where you have the opportunity for break down, the opportunity for misinterpretation.
So, it's pretty much anywhere there's a knowledge transfer, whether it's an internal escalation or an external escalation. When it actually transitions from one person's hands to another person or another team's hands. So, every step that we're actually talking about here potentially could be a place for break down, which is why documentation is so critical.
So, another point that I want to address is actually the resolution workflow. The reason why I want to bring that up is that it kind of helps set the stage for the need for these types of solutions, help desk solutions, to manage this entire process. We've talked about it here and there, but one point that really stuck with me in my conversations leading up to hosting this session was that you need a lot of different tools in your tool belt in order to get the job done-- not just one. And you need the right ones too. A good blend of them. So I think a good way to illustrate that is to look at the entire process that a ticket will go through since the moment it is initiated, and what's needed here. So, I think you had some comments on that, right Kevin?
Yeah, there's a couple different things here that really touch with me. I think really when you get down to it, help desk systems that are running inefficiently or are very, very small, hit three of these. They hit ticket creation, assignment and routing and then closure. And that's it. But that's not really the workflow. That may be what's actually being done to the ticket, but the workflow is actually more than that. So, it's the ticket creation leading to the routing and assignment, leading to the asset tracking, which is pretty much necessary to be able to troubleshoot problems, provided they are a universal problem for everybody. Then, remote access-- same kind of thing. If it's an endpoint issue, you need to be able to remote access; you need to be able to have management tools there. You need to make sure you can actually see the running processes, kill services, restart services, what have you. Then you've got to worry about the resolution. Resolution's the part that I always felt was most important to actually list, "Here is everything we did and this is what solved it." And then the last one, which I think a lot of people kind of forget, is customer satisfaction. Now, that depends on each organization. But if we got a report back that somebody was not satisfied with the way their ticket was handled--either because of timing, or because the information was bad, or, God forbid, the person was rude--then this is information we need back. Now, this is something that I've had to deal with as a help desk technician and then a team lead, and trying to implement things like this. But this is a general workflow that should be working for everybody.
I think, Bryan, you also mentioned this earlier-- the need for tracking. There's a number of different ways that a business can do that. They can collect information at the close of every ticket; they can send out surveys for customer satisfaction; there's a lot of different areas that they can focus on here. And I think it's super important for an MSP, right?
Yeah. So, actually the most important step here is the remote step on the MSP side of things. Because the one thing that's different from an MSP than any internal organization is the fact that you're distributed. More and more organizations are distributed. Remote workers are more popular these days, so it's not unique to the MSP space. But it certainly is true for MSPs that your end user does not work in your office. That's 100% always true. So, the ability to remotely access and troubleshoot the problem without having to go onsite most of the time is key to the profitability. Onsite visits are necessary when they are required. However, keeping that down, resolving more offsite and remote is really key to making sure that you have a profitable experience and a good experience for the MSP. The other thing is-- this is more globally. As far as the tools go, yes, there always is a lot of tools to do the job, but people tend to prefer to have one tool that can do everything for them if it's possible. So, the idea to have tools that can follow them through their workflow, whatever that workflow might be, is really key as far as an efficiency perspective. The more tools you try to get a technician to use, the harder it becomes with each success of addition. So making sure that you have everything as integrated as you can is really key to building the habits that are going to drive success.
So are there ways to streamline this process? We mentioned the need for a remote control tool to kind of help lower that mean time to resolution, and get that problem ticket resolved. What else could they be looking for in a solution, or in addition to, in order to help with this?
So, we've mentioned a few things. We mentioned knowledge being really important. So, resolving a problem one time is great, but if you document that, you can resolve a hundred problems in the future. You can let that resolution live on beyond your ability to implement it. Most help desks understand that that's really important--MSPs as well. But having a system where that knowledge is built into your process is really important. You mentioned remote control. Just having that remote control access being super, super easy to initiate-- super, super easy to use, and fast and reliable. That's really your touchpoint. Do you have any other thoughts on that, Kevin?
No, those are the two big ones for me. Being able to make sure that you collect the information. You have it brought to you in your ticketing system. And actually just making sure all the stuff is integrated because you're absolutely right. If you give a guy 15 tools to do a thing, then they're not going to spend the time to learn all 15. Now, if you give them one, maybe even just two tools, and say these are the two you're going to use all the time. This one does when the coin is heads; this one does when the coin is tails. That's it. Then they can follow that logic. If you've got all of those 15 tools, that's for your level twos; that's for your Level 3s. They are the people that actually have to worry about the really complex things. And typically, they are the ones more worried about servers, as opposed to end users, and the tool set shifts slightly. But you need to make sure you get the right tools in the right hands to make sure your help desk solution, start to finish, actually continues to grow and become self-service like you said. Sometimes, the end user says, "Hey, I'm having a problem with my internets." Let's hope that's not the one. But if they say that, then maybe the solution says, "Hey, you're having problem with your internets. Did you try this solution first?" Then they can run through that and say, "Oh, now it's fixed. I can either close my own case or I don't have to submit one."
But I think you hit on a really important point there that documentation, knowledge management, having streamlined tool sets-- it's really key to trying to scale up and streamline your help desk. At the end of the day, what we're trying to do is service customers better, resolve problems quicker, and ultimately offer the best possible support not matter what type of organization we are, and no matter who we're servicing. It's job one to resolve that issue and service that customer as quick and as awesome as possible.
Yeah, you really want to-- as painful as calling the help desk can be-- you want to try and make it as delightful as possible. So, a lot of these tools, a lot of these steps can actually help you move towards that goal.
Well, thanks for sharing that point, Kevin.
Well, that's all the time we have for this session. If you'd like to learn more about this or other help desk support related topics, please consult the helpful resources section. If you're in the market for help desk software, I encourage you to check out solutions offered by SolarWinds--Web Help Desk and MSP Manager. We've also included free trial links to both of those solutions in the helpful resources. Thanks Kevin.
No problem. Love being part of THWACKcamp.
And thanks, Bryan.
Happy to be here. It's been a blast.
Thanks to all of you out there for sharing your comments and support war stories. I hope this was as informative and fun for you as it was for me. Enjoy the rest of THWACKcamp. [Upbeat music]