5 Ways to Improve Service Desk Performance

Written by Lindsey Semon

The following consists of excerpts from the Service Desk Horror Stories episode of our podcast, This is ITSM. Fear not if the whole thing looks a bit TLDR for your taste. Each section stands on its own, so jump around however you’d like.

Keep Your Service Desk in the Loop

Amanda: One of the biggest complaints I hear from the customer or end users is that the service desk doesn’t know what’s going on. I imagine this is something every organization deals with – it’s certainly come up at all the company’s I’ve worked with and for. The service desk is the face of your IT organization, and if you don’t keep them in the loop, it’s going to make the whole organization look bad. And they usually get blamed for this but it’s not always their fault.

Ari: It’s often not their fault. Even when they have the ability to know what’s going on, they often don’t realize it, which is definitely an interesting problem. It’s one of those “I don’t know what I don’t know” kind of things, so it becomes lights out and hands off.

Amanda: One easy way to make a dent in this is to invite someone from the service desk to all of your major meetings. Otherwise, it becomes someone else’s responsibility to go back and translate all the information to the service desk and, inevitably, things will fall through the cracks.

If you have them in the room, they can ask questions, they can say, “Wait a minute, this is actually going to have a really big impact on the users.” Service desk techs are the people who understand that impact the most. That would be my number one easy win. It doesn’t even have to be a manager, just pull somebody in who can sit and listen and go back and relay what’s going on to the service desk.

Ari: Absolutely. At my last organization, we put one of the desktop engineers who sat with the service desk in on the technical reviews for change management. They didn’t have an approval and weren’t part of the process necessarily – they just talked through some of the issues with the group. This gave them visibility into what was going on. So they were, in the terms of the RACI model, they were an informed person, and I guess sometimes consulted, but mostly informed. And that way, they were able to take back the information to the service desk like, “Hey, they’re doing a patch on the exchange server, so if we get 40 calls tomorrow morning, it’s because maybe it didn’t apply all the way, and they didn’t test the exception.”

From there, the service desk took the initiative to start sending communications to the businesses that they know utilized those services heavily, saying, “Hey, we have an update going on. If you have an issue, let us know.” Granted, that would sometimes result in people calling because they thought they were having slowness or issues with something. Like when you’re bleeding but it doesn’t hurt until you see the cut. They’d see this notice go out that the exchange server was getting an update, and then the next morning the service desk would receive 10 or 15 calls that were like, “Hey, my email’s running slow,” and it really wasn’t running slow. But I think that the benefit of sending those communications far outweighed the few hypochondriac users out there.

Get Agents in the Habit of Logging Tickets Immediately

Ari: We’ve had a few conversations with the IT Skeptic about incident logging and the woes that come along with it – users being notified when a ticket is created, when it’s updated, that kind of stuff. Recently, we’ve started to hear, “Oh, that shouldn’t be the responsibility of the service desk. My new Cherwell implementation has a self-service portal where they can go and look at their tickets.”

While the self-service portal is great – and definitely a way to extend the service desk beyond just an individual to a website or a portal – it doesn’t absolve service desk technicians from being able to look up that ticket number or user, know what’s going on, and be able to put some context to it. You can’t expect the end user to be able to go to that portal, consume the information on the ticket, and know what it means. They may go to the portal have questions about what they see, and call in. The service desk must be able to point them in the right direction.

Amanda: A lot of service desk agents have a bad habit of writing down all their tickets, troubleshooting them, and then every hour, or maybe even like twice a day, putting them all into the system. When you do this, end users think nothing’s going on. If they don’t see that confirmation email after they’ve spoken with you, they’ll have a bad perception of you and the service desk. It doesn’t matter if you’re resolving the incidents or not.

It can also really mess up reporting. If tickets are closed as soon as they’re opened, then your Service Level Agreements (SLAs) aren’t going to be accurate, your data’s not going to be accurate, your times aren’t going to be accurate. So, there’s a big ripple effect there.

Ari: On top of that, let’s say you have a 20-person help desk and all of them wait to log their tickets at once. If all 20 people saw two of the same incidents but don’t log them all day, you might be missing a problem going on that your problem management or your operations team can take a look at and say, “Oh god… ” Say 20 of these same types of tickets have come in, but if they’re not getting that until six hours after the calls came in, it’s a lot harder for them to quickly do any kind of root cause, or even Known Error to the portal, or workarounds, or whatever. There’s no ability for you to get ahead of that, and so you’re being 100% reactive.

Amanda: Yeah, that’s a really good point. I’ve been managing service desks and other teams for over 12 years now. One thing I did with my service desk when I was trying to improve this metric, it sounds really mean, I’m not really that mean of a person, but I took away all of their steno pads and notebooks. And I’ll tell you what, those tickets got logged because they had no choice.

Having the discipline to log the tickets right away also ensures things like priority and categorization don’t get dropped. The incident may not even be resolvable over the phone and need to be escalated right away. Getting the tickets into the system right away ensures all this information will be collected.

Ari: A lot of times, service desk techs think logging a ticket means they have to log it through completion or perfection in one sitting. Part of the aversion I’ve seen many service desk techs have to logging tickets right away is that they think they have to be logged to completion and perfection on that first go. All it really means, though, is hitting that ‘Create new ticket’ button, typing up a description exactly how you would jot it down in a steno pad, and setting a priority and category. Then, exactly like you said: It’s there, the reporting can start, the SLAs can start, the customer knows it’s there, and things start to happen. You can always go back and fix later. It’s not like that ticket gets locked and you can’t do anything to it after you’ve put it in. It doesn’t have to be perfect on that first entry.

Amanda: People also tend to get scared if they’re tied to SLAs that are then tied to performance. You have to trust your agents. If there is a problem, and maybe you need more staff, putting all your tickets in at one time is just going to prevent those problems from rising to the surface.

Ari: It’s a challenge because often there’s financial concern tied to that – and sometimes those SLAs are unreasonable. But the problem, like you said, is if they’re unreasonable, they need to be renegotiated. You don’t need to be, forgive me, gaming the ticket numbers.

It can also have a huge impact on availability management – especially if you have people regularly running availability reports or have automatic call distribution. If everyone logs all of their calls for the day at 4PM, for instance, that time will show as the busiest of the day. In actuality, though, 4PM in this example is probably one of the slowest times – because people tend to log their tickets during a lull. You can end up getting a lot of bad data from that. It is definitely a problem that has a big ripple effect to it.

Amanda: And if anyone has an Automatic Call Distribution system and you’re not getting the reports you need, I would highly recommend doing some reading and studying on it, because it’s a tool that you have in place that can give you tremendous results with productivity for your staff if you report properly. It’s also a great way to communicate with your users. Most of them allow for a message of the day, so if there’s an outage or some other issue, so when people call they don’t have to wait to get an agent on the phone; they’ll hear the message and know you guys are aware of the issue, that you’re working on it, and they can abandon the call. The other thing to note there is, if you utilize message of the day well, you should have more abandoned calls on those days. It should be driving your abandoned calls up and your answered calls down, and that’s really what you want.

Identify (& Actually Use) the Right Performance Metrics

Ari: KPIs are Key Performance Indicators, and they are usually driven off of another of our favorite acronyms, which is CSF, Critical Success Factor. You’ll find organizations use these metrics in different ways – Some keep them visible on a customer portal, some only report them to management, some report them to executive management.

Amanda: For example, if you have customers saying, “It takes forever for someone to pick up the phone when I call the service desk,” there are several metrics you can look at to determine what’s going on and improve. If you have an ACD system like we talked about, you can look at your wrap-up times. How long is it taking your agents to wrap up their tickets?

You can look at your agent availability times. I had a team years ago that I thought was doing a great job. After I started looking at their availability times, I realized they were only working four hours a day. I did a little digging and found out they were working, but not on the things they were supposed to be. Once you have a baseline, you can work to improve that. So your KPI might be to decrease wrap-up time and increase availability time for agents.

Ari: Something you’ll learn in many of the ITIL courses is that your metrics and KPIs are only as good as the data you’re measuring, and only as valuable as the action you can take from them. I’ve seen a lot of service desks who come in and saw, “Check out this awesome dashboard I have with four billion metrics on it and bells and whistles and lights,” but of all of that data, probably two or three things are actionable and provide an actual health check on what the service desk is doing. It’s cliché, but sometimes fewer is better. And it definitely helps you at least get a beat on where you are for that initial health check – and you can go from there. So you might start out with two or three CSFs and a KPI or two on all of those, and as you move past that, you might identify a new KPI or metric that you want to start tracking – that will get you beyond that first step.

Create Service Level Agreements for VIP Customers

Ari: Another underutilized tool for the service desk is VIP designation, which starts with identifying those people who will be your biggest promoters or detractors. It’s a horrible thing to say, but the squeaky wheel effect is definitely pervasive on the service desk. To avoid this and make sure you’re taking care of VIPs – and those frequent flyer callers – you need to make sure the process is repeatable. Again, if you get this right they’ll be your biggest advocates – but if you get it wrong they can do a lot of damage.

Amanda: Yeah. That’s been a complaint that I’ve heard at every single service desk I’ve managed. A VIP calls in and, even if we resolve their ticket perfectly, gets angry because we didn’t give them that white glove treatment. We didn’t talk to them about their job. We didn’t say, “Oh, hi, we know you’re a VIP.” That’s what they want to hear and – I hate to go back to this again – but it goes back to logging. If you’re not logging your tickets then you’re never going to get to that level of service with your VIPs. If you type their name in and your Cherwell screen pops up and says “VIP,” you can automatically change the behavior. You can’t expect people to do that if, A, you don’t have your VIPs identified, or B, you’re not logging your tickets as soon as the person calls.

Ari: I’ve worked on, god, like 12 different tools, and I know almost all of them have the ability to tie different levels of SLAs to VIPs. I’ve heard a lot of arguments against this, which I think is funny because it really does allow to you to provide a much different level of service. You’re held accountable by an SLA, even if it’s similar to the corporate SLA, and allowing the VIPs you’re working with to see that they have that VIP resolution time on their ticket. If that’s communicated to them in some way it will alleviate that frustration on their end.

So like you said, the VIPs, even if their ticket was handled perfectly, are going to be acutely aware of whether you gave them the white glove service. And if you have this VIP SLA in there, first off, you’ll have the ability to track what that is and what that should be. But also, you’re providing some visibility to the customer, letting them know they do fall into this other category, and we the service desk are aware that you have a high bill rate or your downtime needs to be minimized as much as possible, and that we are committed as a team to get that to you.

This is another place you really need to make sure you’re partnering with the business. Have this conversation with them, because it’s where you get to sell you. You get to show, “Yeah, we’ll commit to this because this is what you need. We’ll get this done, and these are the metrics we’ll be meeting.” It’s completely possible that you’d been meeting those deadlines before you outlined an SLA or highlighted certain people as VIPs, but now that you’ve had that conversation with the business, and they see it, the value of meeting those metrics is significantly higher. It’s like saying, “Yeah, we knew we were great, but now you know we’re great too.”

Amanda: Another helpful thing you can do if you have these VIPs setup in your tool is send automatic emails to IT leadership any time a VIP calls the help desk. One of the biggest gripes I remember hearing from previous bosses was when they’d go to a VIPs office – usually a political appointee of some kind since we’re in DC – and learn for the first time from the VIP that they’d been calling the help desk. If you’ve got those emails generating to the IT Director as soon as the calls comes in, it gives them much more context when meeting with your VIPs. That can go a long way in helping everyone’s image of IT.

Ari: Yeah, how great would it be if your CEO called the service desk because he was having email issues, and your CTO and CEO meet in the break-room to get coffee, and he’s like, “Oh, hey, got my best guys looking at the emails you got this morning. We’ll get it resolved for you by the end of the afternoon.” And you know what that CEO’s gonna think? They got their stuff together…

Amanda: They’re on top of things.

Ari: And if you didn’t say that, it’s not like the team wouldn’t have been on top of it. So, again, this is so much of an image thing, right? You have to manage your ability to show the business the quality you’re providing, not just provide the quality.

Build Priority Matrices into Your ITSM Platform

Ari: The last thing I want to call out has been a big deal everywhere I’ve worked: defining the impact in urgency and priority. So many times this piece gets passed up completely or given a meaningless, arbitrary value. To their credit, though a lot of the tools and training have started to put more focus on it recently. The major platforms out there, Cherwell and ServiceNow and Remedy, they all provide you the ability to define a matrix of high, medium, and low, and does this impact an individual user. While our customers are starting to use these out-of-the-box matrices, a lot of them don’t realize they can customize them to their business. They’re not the bible – they’re designed to be something you identify as a great place to start and go from there.

Ari: We just did a matrix for somebody the other day that looked pretty crazy. It had numbers all over the place and it didn’t make a ton of sense, but it really met the organizational need because they were able to identify a particular type of impact on a particular type of urgency that happened with just this one group. And so they set that as a different value, and that put the value up at almost a corporate level issue, even though it was one small group, because that group operated at such a high level of business function that it raised the value. And so by defining that upfront and providing their service desk almost a blind way to classify a ticket, they knew if this group called and this was the type of problem they called about, that it was immediately this priority. Because it fell into the matrix in the correct spot. Providing that takes a lot of grey area out of classifying a ticket. I’ve had some pretty bad experiences. Have had any good experiences with that?

Amanda: I’ve had good experiences with it, with getting it right, but in order for it to be meaningful you can’t be constantly fire-fighting. So, what’s a priority for? It’s to prioritize your ticket so your agents know which tickets to work on first. And anybody who works on a service desk knows you’re always trying to help the person who’s screaming the loudest, and priorities often get pushed aside.

Ari: The trick with that is, the priority needs to carry some weight, and that needs to be understood by the organization internally. Sometimes that means, as a service desk manager, you have to take one of those hard calls or have that tough conversation with somebody, to say, “Look, I know that you’ve got a problem and I know that you’re screaming the loudest, and I know that you’re not gonna be happy, but the deal is, I’m resolving five other P1 and P2 tickets in the time that I was gonna resolve your P4. Just because you are screaming louder doesn’t mean that you get to trump those priorities.” But the trick is making sure there’s an organizational understanding of the system.

Amanda: 100%.

Ari: And that’s the hardest part. Again, it comes down to communication; communication from the service desk to their managers, from their managers to their managers, even to the executive level. They have to understand that you guys – as an organization – put together a priority, and that priority means something to you. It’s not an arbitrary value and it will drive how the service desk moves through tickets.

And yes, occasionally there’ll be an exception, where the person who’s screaming the loudest, the priority ticket they have, and who they are might just escalate them, or what they’re working on might just escalate the priority. But in those cases, maybe you re-categorize that ticket and set it to a higher priority and then continue to work though the priority tickets that you have open. The problem is that as soon as you start letting that fall by the wayside, and you let people trump that based on who screams the loudest, you start to run into that problem where, if everything’s a priority, nothing’s a priority. I wish there was a silver bullet for that, but I don’t know if there is. I think it’s really just, you have to have buy-in from a lot of different people to made that really, really successful.

There will be occasional exceptions to this – where the person who is screaming the loudest, combined with the priority of the ticket they have and who they are or what they’re working on, may just escalate the priority. In those cases, maybe you reprioritize the ticket, then continue working through the priority tickets you have open. The problem is when you do this too often, letting people sidestep the system by screaming the loudest, the system itself may fall to the wayside. It becomes a slippery slope where, if everything is a priority, nothing is.

Amanda: Yeah. That’s a tough quick fix because you have to have your SLAs documented and published, and everyone has to have a really good understanding of them. Your service desk has to be able to explain it. And you can’t have people in your IT department running their own help desks, because that is just going to punish the people who are actually following the process.

Ari: Yeah, that can mess your whole system up. I can’t tell you how many times I’ve seen agents pull a ticket that looks easy and quick to resolve then get wrapped up in a P3 or P4, letting P1s and P2s age because they prioritized getting something off their plate over the process. It really is a case-by-case situation, but you need to have an understanding as a help desk around what that means. If there’s a ticket that’s first call resolution, super simple, you’re going to fix it right there on the phone – even if it’s a P3 – maybe you do take care of it, and that trumps priority. But the second you’re off that call and you start working another ticket, you can’t fall into the trap of saying, “Oh, well this P3 is pretty similar and it’s easy – I’m gonna jump on that and just get it out of the queue.”

You have to take care of the priorities – keep working through that matrix the way it was designed. And sometimes it’s tough because you think, “Oh, if I’m eliminating the ones at the bottom, there’s less to do and then we can focus on the others.” But if anybody out there has ever worked on a help desk, you know that eliminating the tickets at the bottom only makes room for the new tickets at the bottom as they continue to file in.

Amanda: Cherry picking is a big, big problem.

Ari: And that will not be on this episode, ’cause that is a… [laughter] It is not a simple fix.

Amanda: No, it’s not.

And Last but not Least: Service Desk Horror Stories

Ari: Now for my favorite part: service desk stories, nightmares, best case and worse case. So, I’m gonna put you on the spot. We all heard the service desk nightmare from Comcast, where the guy calls to try and cancel his service and ends up on a 45-minute phone call, where the guy keeps asking him, “Why would you wanna cancel the best internet service provider in the world?” That one will be tough But I’m sure we’ve all had some best or worst case scenarios, whether we worked them or whether we were the horrible victim.

We all remember that nightmare from Comcast, where the poor guy called in to cancel his service and ended up on the phone for 45 minutes with the rep asking why he’d want to cancel the best internet service provider in the world. I’m sure that one will be tough to beat, but I know we’ve had experiences – good or bad – of our own and I’d love to hear yours.

Amanda: This is going to date me, but one of my favorites had to do with troubleshooting a floppy disk. My rep came back cracking up after going to this person’s office to address the issue. We were in a government facility, so all of our mail had to be x-rayed before it came in. Well, the x-ray had completely destroyed the 3.5 floppy disk. So, my rep shows up to find this person attempting to shove what had essentially become a melted piece of plastic into their machine. It was so funny. We had a Wall of Shame in the back where we put funny things that happened – this definitely made it.

Ari: I have a terrible one. It happened to a co-worker, and it was probably the funniest thing I’ve ever heard. There was an application we used as an organization that would often lose connection to mapped network drives, so the user would have to refresh their My Computer icon. So, this lady calls up the help desk and my friend answers the phone. He’s talking her through the problem, he goes, “Oh, this is a simple fix. Right click on My Computer and click refresh.”

Twenty minutes later, the door opens and the lady walks in and starts walking over to my friend’s desk, and he says, “Oh, did that not work for you?” And she goes, “Well, you told me that I needed to right click on your computer.” So she had come into the office to right click the computer.

Communication, right? We assumed she understood My Computer within her computer but she didn’t. Luckily she was a good sport about it and it was funny for all of us. But that was one of those where you’re like, “I didn’t know I had to clarify that.” But that’s a level of service thing – don’t assume your users know anything, make sure you’re helping them and get them to done.

Amanda: My first training job ever, out of college, we couldn’t say “hit start” because someone in a class actually hit the computer.

Ari: No.


Amanda: Yes. Never say “hit.” [chuckle] People can take things very literally.

Ari: That actually happened at my last job too. Somebody told a user at a remote site that we needed to bounce the router, and they threw the router on the ground. That was an actual thing. They were like, “Are you sure?” And the person was like, “Yeah, I’m sure.” And they went back and forth, I’m sure, thinking like, “Yeah, no, it’s okay. You don’t have an internet connection. Of course you can power down your router.” And what the person on the other end of the line was like, “You want me to throw this on the ground? Are you sure?”


Ari: “You want me to bounce it, really? I don’t know about that.” So, that’s always fun.

Ari: Okay, last one. I worked at the support bar at a – let’s call them a fruit store – years ago. A guy came in needing to replace their MP3 player, and he asked how much it weighed. I thought, “That’s a great question. I have no idea how much one of these things weighs. Let’s figure this out.” So I looked it up and told him. He looked back at me with the most genuine look in his eyes and said, “And how much does it weigh after you put all your music on it?”

It took every ounce of energy in me not to bust out laughing. “I dunno, depends on how heavy the beat is…” It was pretty fun.

Want to take the pulse of your ITSM program?

Our Assessment Readiness kit has everything you need to determine where your processes are now - and where there's room for improvement.
Download the kit

Originally published December 12 2017, updated December 12 2019