Phrases are critical to letting employees make the right decisions when you’re not around. They allow you to avoid the micromanagement trap. In this series I’m sharing with you the phrases that have made a great impact on my MSP.
- We’ll get fired if a client can’t print, but we won’t keep them because they can print
- Don’t make a plan based on the exception
- Do I really need to know that?
- It’s always DNS
Did you ask the question?
A large part of being a technical support person is understanding the problem that you’re trying to solve. I’ve had techs spend far too much time resolving a problem and then be dismayed at why the client isn’t happy with their solution. The reason the client isn’t happy is because the tech failed to ask the question. The thing that I want in the techs head is to hear my voice saying, Did you ask the question? When they hear that, then they should ask the question, What is it that you’re trying to do?
What is it that you’re trying to do?
Asking the simple question, What is it that you’re trying to do, is the key to making sure that you understand the problem. If the client doesn’t come to you with the context for the problem that they are having, then the tech needs to ask, What is it that you’re trying to do? Context is important because often the user might be trying to get something to produce a result that can’t be achieved by taking the action that they’ve decided upon. If they haven’t asked the question, then they could end up solving the wrong problem and we never want our techs to be in that position.
For example, if the client says, my email isn’t sending. The tech might think, the email server is down, it’s DNS, there’s an internet outage, Microsoft 365 is down, Outlook is disconnected, they’ve come disconnected from the WIFI access point…or really any of a long list of potential solutions. If the tech just dives in and starts working through the list of problems, they could be looking for a long time before coming back to tell the client that they’ve checked everything, and email is working fine. The customer would then say, so then why can’t I send this file to my customer? If instead the tech has first asked the question, then they wouldn’t have spent any time looking through the vast list of reasons why email isn’t sending. We can cut out all that wasted time by asking the client, What is it that you’re trying to do? and the client would reply, I’m trying to send my customer this file and I keep getting an email error back. A quick look at the error message would then tell the tech that the file is too big to send via email and they could help them deliver it another way.
Another example occurred recently when an owner asked for the password to an employee’s account. Of course, we told them that we didn’t have the password, but we could reset it, if necessary. But before going down that path, the tech thought to ask a variation of, What is it that you’re trying to do? and asked is there specific information that you’re looking for? because we might not need to reset the password to give you what you need. Expecting the answer to be that they needed to find some specific email or a specific topic, in which case we would offer to do the search via eDiscovery and the user wouldn’t know or be disrupted. But no! That’s not at all what they responded with. Instead, the answer was that this person receives emailed leads, and he needs to see them too. Without asking the question the tech would have started down the path of a completely different solution. Instead, the client was introduced to Shared Mailboxes as a permanent solution. As if often the case, the client didn’t know what to ask for. The tech has to ask the question. Hence, the mantra, Did you asked the question?
This one phrase prevents a lot of missteps due to assumption.
All we do is support IT professionals. Help for IT Pros, Super Secret News, Security community, MSP Legislation community, Kits, papers, MSP training and more. https://www.thirdtier.net