The Basics of Troubleshooting
I work in a call center. So that means I talk to a lot of customers on a daily basis from all walks of life. I've been in the industry for over 8 years now. I am currently in a second-tier position, meaning that almost all of my customers have worked with a previous technician before getting to me, so I rarely know what level of support the customer has received before they have talked to me.
If you've worked in a support industry yourself, you know that you can never trust anyone but yourself. This means that the customer often doesn't know exactly what information you need and is, without their intent, not telling you all of the information correctly. This also goes for the previous technician.
Furthermore, every time you get a call, you have to understand, the previous person that the customer just talked to, no matter how comptitent they may seem or how well you know them personally, was not able to solve their issue.
I've worked in structured call center environments for over 3 years now, and I'm going to share what I've learned about how to handle a call, in general. I will not be including anything that has been taught directly from our internal materials, but I will be providing some tips that I've learned myself along the way.
1. Don't assume anything and start from the top
This is your best friend. Any time a customer tells you that they did something, see it for yourself. If the previous notes tell you that they checked for something, check again. Unless you've seen it yourself, it didn't happen. I cannot tell you how many times I've seen notes saying:
I checked these 18 different things
And finding that the first one is not correct. This is not to say don't read the notes, however. This is often the only information you will have to get started and can prevent from having the customer be forced to explain themselves all over again. Just make sure to take everything at the beginning of the call with a grain of salt. All information is false until proven true.
2. Try it yourself
Have the customer show you the problem just like they normally would first. You may find the solution simply in their attempt to show you how it's done. Now it's your turn to do the exact same thing, which will seem silly, but it's important. You're about to either prove their point and appear to waste time or prove them wrong and make them look dumb. Neither of those are fun, but can be an invaluable step for determining a few things:
- If you can't make it happen:
- Maybe the issue is intermittent. Does the customer say this definitely happened in the past?
- Maybe the customer was doing something wrong. If you just did it correctly, go through everything they did to replicate it one more time slowly. There could be something that is natural to you that they are missing.
- It could be that something has changed since the last time they tried. When this last happen? This may seem silly, but I've had customer's ask me about an issue they had 3 weeks ago, but it hasn't happened since.
- If you can make it happen, you can start to do the real troubleshooting.
3. Narrow it down
I would say this requires the most technical knowledge out of all of the steps. Mostly because poorly isolating where the problem is means you're troubleshooting the wrong thing. Also important is the fact that you can't isolate if you can't replicate. If you can't see the problem happen, you won't know once it's fixed.
This is where you start the process of determining the location of your problem. This varies from one industry to the next, but we'll use a common example of "I can't connect to the internet." Think of this as a challenge to figure out as quickly as possible parts are working.
A few examples of things you would look for are:
- Does the computer have an IP? (This isolates the issue to a local connection)
- Can you ping a raw IP address, not just google.com? (This removes the DNS server from the equation)
- Is this the only computer unable to connect? (This would isolate the computer)
- Does the computer have a connection to Wi-Fi? Do the others? (This may isolate the wireless access point)
- Are devices that are connected via ethernet experiencing similar issues? (This would put the issue between the router and the ISP)
- When you connect a computer directly to the router/firewall, do you get the same issue? (This eliminates switches and other routing hardware)
- If you plug a computer directly into the modem, does it connect to the internet? (This eliminates the external internet connection itself)
And these are just a few of the examples of what could cause the internet to go out, but you should be getting the general idea. The idea is to check every device along the chain until you stop encountering the issue, working inside out. In the above example, the chain would be:
Computer > Wireless access point > Routing equipment (switches, cabling) > Router/firewall > Modem > ISP/Internet
If at any point along this chain, things start working, STOP. There are too many times that I have seen technicians keep troubleshooting other parts of the network once they have isolated the issue. If it walks like X and talks like X, it's probably X. Once you found something that works, make sure that thing is still consistent. You want to avoid troubleshooting something intermittent on the wrong piece of hardware. That can also be a massive headache.
4. Figure it out
This is often the most difficult and tedious step. You now have to take all the info you gathered from your testing and put it out in front of you. Chances are, if you've made it this far and haven't already caught the issue in a previous step, you haven't encountered this problem before. It's research time. Google is your friend, but so is internal documentation and your fellow coworkers. If you think something about this is something you feel another person has come across before, ask them, but make sure to point out that you're not opposed to doing your own research if they don't know right away.
If can be quickly misinterpreted that if you're asking for help, you're unwilling to find out on your own. A simple, "Hey. I was just wondering if you already knew the answer to this..." before what you're about to ask will prevent them from doing your work for you. If they don't have any suggestions, start digging away at every resource you have. This could be an internal documentation, a ticket searching system, or your good friend Google, as I mentioned before.
Knowing how to search is arguably the most difficult part of troubleshooting. I recommend doing your own research into what makes a good Google search. It's a nearly impossible task to teach, but the more you do it, the better you get.
5. Try it out
There is nothing more frustrating to a customer than having someone provide a solution they know will work, only to have the call end, they try it, and it doesn't work. Never leave a situation where you could have confirmed that it works. If they say they can't test, that's on them, but always do what you can. That way, if it comes back, you can definitively say it was working when you left it and the responsibility is back on the problem itself.
I've gotten calls where all it took was a quick and simple test by the previous technician to know it was never going to work, but they just wanted to be off the call and onto the next. This is probably the number one reason I've had upset customers in the past.
6. Notes, notes, notes
Notes are magic. They are the quickest way to CYA. If it's not in the notes, it didn't happen as per step 1. Also, if you're unsure of something, note it. If you're not confident you did something right, it's okay to write that in the internal notes. That's a lot better than saying you did something right when you didn't and it's what makes step 1 necessary.
Conversely, if you did something, make a note. If the customer added a detail, add it to your notes. Everything is relevant. The reason this is so important is that if that customer asks you about that details and it's not there, it looks bad on you. That shouldn't be the case, but it is. They're not thinking about the tech that didn't leave the note and said they did. They're thinking about the one they just asked and says they don't see it.
Also, don't make your notes incredibly wordy. This is an example of a good and bad set of notes using the earlier example:
John said that his internet wasn't working, so I made sure his Wi-Fi was connected, which it was. I then made sure that they could access the local server, but they couldn't. After checking the IP address settings, we found out that the DNS server was somehow pointing to a weird address. I put in the correct DNS address and it seems to be working now.
internet not working-found dns problem and fixed
- User jsmith on COMP-239 unable to connect to internet - Wi-Fi connected and computer has local IP - Can ping 188.8.131.52 - Cannot ping www.google.com - DNS was set to incorrect IP: 184.108.40.206 - Switched DNS back to automatic and verified internet is now working correctly
Notes should tell you everything you need to know and nothing you don't. Some of these points will be subjective, but I tend to follow the above format. Keep all steps on their own lines and separate them with an identifying character so you know when word wrap is happening. It makes things very quick and easy to read and can save the next technician some serious time if this same sort of thing happens again.
The bad notes examples may seem over the top, but I'm not joking that I've seen notes worse than this. You always have to think about what kind of notes you would want to see the previous technician write. Ask yourself: If I wasn't on this call and didn't listen to the recording, would I have enough information to pick up right where I left off? What's missing? Also, make sure that if it's a long case, that you're correcting or removing information that is no longer accurate. That's a really quick way to confuse someone.
- History - Take in all of the information from the case, with a grain of salt. Any information missed here can lead to rehashing what's already been asked or what's already been done.
- Replicate - Make sure you can make it happen and figure out the fewest amount of steps to make it happen again.
- Isolate - Figure out where your point of failure is and focus on it.
- Research - Use all of your available resources and try to find your solution. This take the most raw skill and is the key to being a good technician.
- Confirm - Show the customer that it works and have them try it themselves. This take the responsibility away from you if the issue comes back.
- Notes - Remember, if you didn't write it down, it didn't happen. All of the previous steps are forfeit if you have nothing to show for them.
Final thought: All of this is obviously subjective, as a process can evolve over time, but based on my previous experience, following every one of these steps in order, every time, has led me to a quicker solution than me thinking I'm smarter than the problem.