There are a lot of acronyms floating around the average support desk, but one that really matters to both you and your end users is MTTR. However not everyone understands just what it means and, more importantly, how to keep it as small as possible.
The first thing that needs to be addressed is what the “R” in MTTR actually stands for. I’ve always thought it was “resolution,” but I’ve been told that it should actually be “repair.” Or “recovery.” Or “resolve.” Possibly “restoration.”
Regardless (See? I’m stuck on “R” words), what MTTR comes down to in practise is the length of time your end users spend twiddling their thumbs after logging an issue with your support team. So how can you keep that twiddling time to a minimum without having to massively expand your support offering? Especially now that the support team is further removed from end users who work remotely — a trend that’s likely to continue even post-pandemic?
Below are five tips to follow to make sure that the mean time to <insert word here> is as short as possible.
1. Data, data, data.
There’s a very simple maxim to follow when it comes to supporting your users: You can’t fix what you can’t see.
Sure, you can make educated guesses and check for known issues, but as anyone who has sat on the phone while a support engineer works though their checklist (Have you tried turning it off and on again?) will tell you, this can be time consuming and frustrating. Without a foundation of data specific to that end user, your team will be shooting in the dark.
The extra tricky part is that in order to really improve MTTR, you need to be collecting data before the problem even happens. Otherwise you will be left with the situation of enabling your data collection and telling the user to call back when the problem happens again.
So does this mean you need to be constantly collecting data on everything that is happening on an end user’s system? In an ideal world, yes, you do.
With a digital experience management (DEM) solution such as Lakeside’s Digital Experience Cloud, powered by SysTrack, you can collect this granular data through an agent running on the end user’s device. That way, you have a continuous feed of system performance and usage that saves you the trouble of needing to contact the user and helps you find the real root cause faster.
2. Get to the good stuff.
Now you have a huge amount of data collected. That’s only the first step. Without a way of making that data consumable you might have just increased the MTTR while your support desk digs through all the extraneous information.
So along with that data, you also need a method of sifting through it to identify what issues are a relevant cause for concern, and to help distinguish correlation and causation. You then need to make this available to your support desk in a way that can slot right into their existing business as usual (BAU) process.
That’s where the AIOps functionality of Lakeside’s Digital Experience Cloud comes in. The huge amount of data collected — more than 10,000 data points every 15 seconds — is constantly being analysed for new issues or deviations from previous behaviour. When these occur, a sensor is activated to highlight exactly what and where an issue has been spotted.
3. Find the right person for the job.
In environments with multiple levels of support teams, there is always time wasted while a new issue finds the appropriate level. Despite one in five users claiming to be “digital experts” in a recent Gartner survey, it probably isn’t the end user themselves (unless they are given the information and steps they need to fix the problem themselves, of course, but that’s a whole other blog post).
Your front line team needs to work through their checklist before deciding it’s something that needs to be escalated to level 2. Level 2 needs to start their own investigation, often repeating steps, before deciding to escalate again or push it back to level 1. All this increases the MTTR and adds to the users’ perception of a service desk that needs to get their act together.
When issues can be identified quickly, the appropriate level of support can be easily assigned. The sensors mentioned above can also be integrated with service desk tools such as ServiceNow to automatically raise tickets with the appropriate categorisation to make sure the right team is dealing with them from the start.
4. Treat the cause, not the symptom.
So you have your data and the right team is looking at it. That’s already a great start for reducing your MTTR. The next step is making the data actionable, but in a way that fixes the problem permanently so users aren’t clogging up the support desk with repeat tickets.
This links back to step one, the need for a lot of supporting data. A recent example I’ve come across was a customer’s help desk getting complaints from a user that their Citrix apps were running slowly in the afternoon. This, to the user, was an obvious IT issue related to different time zones coming online and stretching the company resources (again, one in five users are self-proclaimed “digital experts”). Using SysTrack data, the support desk was able to see pretty quickly that the user’s Wi-Fi signal quality and bandwidth were dropping off a cliff around 3 p.m. every day. It turned out that when the kids came back from school, the user moved to a different room of the house to continue working. One Wi-Fi signal extender later and the “Citrix” issues were no more.
Another user complaint about Microsoft Teams freezing during meetings was traced back to their machine running low on memory. IT was able to trace the issue back to the user’s habit of never closing browser tabs, and the 72(!) tabs they had left open were consuming an understandably large amount of memory.
In both cases, the problem the user was reporting was just the symptom of an underlying issue that could only be answered by having access to all of the data.
5. Automate when possible.
Ask any support desk worker and they will tell you, with varying levels of frustration, how much of their time is taken up by simple repeated issues. Ideally, what you want is a situation where these recurring issues are dealt with automatically at endpoints, without the support team needing to intervene at all. With SysTrack, this can be covered by automations associated with sensors. These can be simple (or complicated) scripts that are automatically kicked off when certain conditions are met.
Automate actions for different sensors — including disk space cleanup — using SysTrack Configure in Lakeside’s Digital Experience Cloud.
For example, one customer with an ageing hardware estate had problems with systems running out of disk space. The method they had for dealing with it involved manually running scripts that checked systems remotely, looking through the data these scripts returned, manually copying over the list of systems with disk space problems, and running another set of scripts to clear temp files from them.
This took up more time that you’d expect owing to the need to nurse the scripts and analyse the results. This whole process was replaced by assigning an action to one of SysTrack’s sensors (low disk space) which deleted temp files and emptied the recycle bin. Now a task which took a support team member a few hours each week happens automatically on each endpoint.
What this meant for the customer was fewer tickets coming in from users with an easily fixable issue, and more support desk resources available to deal with the more important tickets that were coming in.
Get Started Reducing MTTR
I’m still undecided what the R in MTTR should really stand for, or that it matters to anyone except me, but effectively reducing MTTR means having the right data, at the right time, delivered to the right person. It also means looking deeper into the issues your users experience and fixing the root cause so the problem doesn’t become a regular occurrence.
Shouldn’t be too much to ask, right?
Well, that depends on your organisation’s mean time to readjust. With the right approach and tools in place, end users’ thumb-twiddling can soon become a thing of the past.