In around 2003 I worked as a level one tech for a very large customer contact center (1,500 call center agents) for a major American hardware vendor. This was around the height of adware and other greyware hitting Windows XP. Our customers were calling us frantic for technical support: “I’m getting a hundred pop-ups every time I open Internet Explorer!” Or, “I’m trying to close these pop-ups, but they keep coming back even faster, I feel like I’m playing whack-a-mole!”
Browser hijackers (BHOs) were all the rage in those days, and an operating system reinstall (OSRI) was the last resort to fix the problem. HijackThis, Spybot Search and Destroy, and Adware were my tools of choice for combating these nasties, and back then consumer based antivirus was nearly non-existent.
Our contact center had no agent-based remote control in those days. Everything back then was done over the phone and as technicians we either worked from knowledge base articles, Visio diagrams, or from documents we would build for our own troubleshooting steps.
Moreover, all this troubleshooting was communicated blindly to a customer over the phone or through email. Troubleshooting a computer remotely was an exhausting effort back then, compared to today. An OSRI meant a minimum hour-long call and was used sparingly to avoid having to get the customer to backup files manually (there was no cloud). And file transfers where exceptionally slow over a USB 1.0—if they even had anything to back up to at all.
With the advent of agent-based remote control and being able to connect to a PC or server remotely over the internet, MSPs and IT departments got the visibility they needed to effectively troubleshoot just like they were in front of the machine. It was an incredible advancement for anyone working in technical support or in systems administration.
Now 15+ years later, when speaking to MSPs about their technical operation and service delivery, the same common theme comes up. I ask, “What steps does your technical support team take before using remote control?” and nearly in all situations the person I’m speaking with answers “…Nothing.”
So one of the first things I do with the MSPs I engage with is suggest there is a better way to make customer interactions better, to lower mean time to resolution, and allow technicians to focus more on higher-priority items or projects.
Over this and the next blog, I’m going to look at five things you can do to improve your technical service delivery to your customers. In part one I’m going to cover discovery to documentation, and learning to listen:
1. Discovery, troubleshooting, and documentation:
Whether your customer requests something from you, like a faster computer, or they have a technical support issue, like a slow computer, the first thing we need to do is to understand what the customer is asking of us. Customer or end-user communication—whether over the phone, email, or via your self-service portal—can always be very hit and miss, based on the end-user’s technical experience.
Taking a few moments and trying to understand what that person is asking of you, can often reduce the complexity in troubleshooting the problem—which I will discuss more below in the example below. The root cause of the problem and what the end-user perceives it to be, can often be two very different things. So taking time to understand what’s going on can allow us to get it right the first time.
When it comes to troubleshooting manually with a user, it’s best to ask a lot of background questions. When did the problem occur? Have you tried to fix this on your own? Is this a performance issue or a productivity problem? The more we understand about the problem, the faster we can resolve it, and sometimes simplify the troubleshooting process.
I don’t think I need to press on you how important it is to document your troubleshooting processes, but if you’re not doing this already, N-able has an excellent documentation and password product in N-able™ Passportal™. When you have a formalized troubleshooting process then anyone in your team will be able to resolve the same or similar issue faster, which will lower meantime to resolution.
2. Understanding what the problem is, can be very different from what you think it might be
I have been guilty of this so many times in the past; thinking I knew exactly what the issue was that the customer was communicating to me, only to complete the troubleshooting process but not resolve the problem.
This typically happens when we take some shortcuts in the discovery process mentioned above. We are all incredibly busy these days, so detailed communication of an issue or problem can sometimes suffer. On top of this, using your fact-finding to simply reinforce your perceptions of what the problem is and not listening to what the customer is telling you won’t help you solve the problem. To effectively solve a problem, we need to really take the time to listen and understand the end user.
In part two, I’m going to look at the role automation plays in improving your customer support. See you next time.