Hi folks. I recently wrote this up as a sort of reminder to myself of what it takes to successfully solve a problem. A little backstory: I was a network administrator for a company for ~15 years and left my job for personal reasons just prior to the start of the pandemic. I remained out of the workforce (by choice, no sympathy/pity needed) for three years before circumstances required me to find another job. This new job was providing technical assistance to dental offices. Knowing diddly squat about the hardware and software bits dental offices use (practice management software, imaging hardware/software, specialized scanning equipment, and so forth), I was in many senses starting from scratch. Adhering to these steps has helped me not only survive but thrive in my new job. The steps are simple of course, and nothing groundbreaking, but here they are:
Step 1: Politely introduce yourself to the client, and if applicable, explain why you are calling them.
Step 2: Observe and document the issue. Every scrap of data you gather, from screenshots to logs will help you diagnose the problem.
Step 3: Based on the data collected, form a hypothesis on why the problem is occurring, and apply the appropriate fix.
Step 4: Test the fix. If it doesn’t work, go back a step.
Step 5: If the troubleshooting process is taking a while, make sure to keep the client up to date on your progress.
Step 6: Still stuck? It’s time to ask for help. It’s not a sign of weakness, simply an acknowledgement that we don’t know it all. Treat those assisting you with the same level of courtesy you extend to the client. This improves your ability to collaborate. Also, be sure to stay engaged in the troubleshooting process. This will help with ticket notes, and you’ll learn something new in the process.
Step 7: Document the resolution, and ensure your team has access to the details of how the issue was resolved. Knowledge not shared is knowledge wasted.
Oddly, being a walking, talking, human knowledge base is only a small part of being effective in the technical support role. Attitude and interpersonal skills are vastly more important in my experience. A couple of examples from the past month about how this played out:
Case study 1: A client had recently reverted imaging software solutions from DTX to Dexis, after DTX proved to be error prone and lacking in features/functionality. After the reversion was nominally completed on the client's servers and workstations (and Dexis was still installed, never having been removed after the "upgrade" to DTX), the client experienced issues with their X-ray sensors not being properly recognized in Dexis. I did what I could, but ultimately had to turn to third party support.
I called Dexis, and was assigned a wonderfully friendly tech. I established a good rapport with her, and we proceeded to call the client to let them know we would be working on their systems. The Dexis tech ultimately reckoned that DTX (which coincidentally is made by the same company) had effectively corrupted the extant Dexis installations, so we would need to go one by one on each operatory, endodontic suite, and hygiene room to uninstall and reinstall the software. We got to work and spent plenty of time chitchatting about various topics to help pass the time. Somewhere during this conversation she had mentioned one of her thoughts was that it might have been an issue with the USB port not providing enough power to the USB sensor; apparently, this was a common issue when using the front ports on a workstation. I filed this tidbit of information away, and we proceeded to have a jolly old time uninstalling/reinstalling and testing out each machine until the client was satisfied.
In an odd stroke of coincidence, this little tidbit of knowledge gleaned from the tech would prove to be instrumental in solving another dentist's problem the very next day. The dentist was frustrated that one of his operatories had an x-ray sensor that simply refused to work. Apparently, this had been going on for years; he had called for support, both from the manufacturer of the sensor and his previous IT support company, and no one had successfully resolved the issue. Wanting to test out my new bit of information, I queried whether the sensor was plugged into the front of the workstation. Bingo. The dentist was dumbfounded that such a simple thing could cause so much trouble, and that no one else could figure it out.
Case study 2: While working on a relatively simple case for a client with a Dentrix technician, we were stuck on hold with the client waiting to verify a fix we had implemented. We started talking, and the conversation turned to a case that had stymied my team for months regarding Dentrix slowness at another client's office. We had checked everything from workstation performance, network infrastructure performance (servers, switches, firewall), and Dentrix had remoted into the server to run database sweep utilities and had even upgraded versions of Dentrix software. The Dentrix technician asked if we had run their port checking utility and a few other tools related to disabling multicast and whatnot. Nothing like this appeared in the ticket notes (which was spread over half a dozen different tickets).
Since we were still remoted into client 1's server, she copied over Dentrix's Level 1 Slowness toolbox, and proceeded to show me how to use it. I thanked her profusely, and the call came to an end when client 1 finally came back on the phone to verify that things were working to their satisfaction. After entering my notes on that ticket, I remoted into the other client's server, and ran the toolkit. The changes it made would require a reboot (to be performed by our after-hours folks) and follow up the next day to see if the fix worked. As you might guess, the kit worked like a charm.
Step 1: Politely introduce yourself to the client, and if applicable, explain why you are calling them.
Step 2: Observe and document the issue. Every scrap of data you gather, from screenshots to logs will help you diagnose the problem.
Step 3: Based on the data collected, form a hypothesis on why the problem is occurring, and apply the appropriate fix.
Step 4: Test the fix. If it doesn’t work, go back a step.
Step 5: If the troubleshooting process is taking a while, make sure to keep the client up to date on your progress.
Step 6: Still stuck? It’s time to ask for help. It’s not a sign of weakness, simply an acknowledgement that we don’t know it all. Treat those assisting you with the same level of courtesy you extend to the client. This improves your ability to collaborate. Also, be sure to stay engaged in the troubleshooting process. This will help with ticket notes, and you’ll learn something new in the process.
Step 7: Document the resolution, and ensure your team has access to the details of how the issue was resolved. Knowledge not shared is knowledge wasted.
Oddly, being a walking, talking, human knowledge base is only a small part of being effective in the technical support role. Attitude and interpersonal skills are vastly more important in my experience. A couple of examples from the past month about how this played out:
Case study 1: A client had recently reverted imaging software solutions from DTX to Dexis, after DTX proved to be error prone and lacking in features/functionality. After the reversion was nominally completed on the client's servers and workstations (and Dexis was still installed, never having been removed after the "upgrade" to DTX), the client experienced issues with their X-ray sensors not being properly recognized in Dexis. I did what I could, but ultimately had to turn to third party support.
I called Dexis, and was assigned a wonderfully friendly tech. I established a good rapport with her, and we proceeded to call the client to let them know we would be working on their systems. The Dexis tech ultimately reckoned that DTX (which coincidentally is made by the same company) had effectively corrupted the extant Dexis installations, so we would need to go one by one on each operatory, endodontic suite, and hygiene room to uninstall and reinstall the software. We got to work and spent plenty of time chitchatting about various topics to help pass the time. Somewhere during this conversation she had mentioned one of her thoughts was that it might have been an issue with the USB port not providing enough power to the USB sensor; apparently, this was a common issue when using the front ports on a workstation. I filed this tidbit of information away, and we proceeded to have a jolly old time uninstalling/reinstalling and testing out each machine until the client was satisfied.
In an odd stroke of coincidence, this little tidbit of knowledge gleaned from the tech would prove to be instrumental in solving another dentist's problem the very next day. The dentist was frustrated that one of his operatories had an x-ray sensor that simply refused to work. Apparently, this had been going on for years; he had called for support, both from the manufacturer of the sensor and his previous IT support company, and no one had successfully resolved the issue. Wanting to test out my new bit of information, I queried whether the sensor was plugged into the front of the workstation. Bingo. The dentist was dumbfounded that such a simple thing could cause so much trouble, and that no one else could figure it out.
Case study 2: While working on a relatively simple case for a client with a Dentrix technician, we were stuck on hold with the client waiting to verify a fix we had implemented. We started talking, and the conversation turned to a case that had stymied my team for months regarding Dentrix slowness at another client's office. We had checked everything from workstation performance, network infrastructure performance (servers, switches, firewall), and Dentrix had remoted into the server to run database sweep utilities and had even upgraded versions of Dentrix software. The Dentrix technician asked if we had run their port checking utility and a few other tools related to disabling multicast and whatnot. Nothing like this appeared in the ticket notes (which was spread over half a dozen different tickets).
Since we were still remoted into client 1's server, she copied over Dentrix's Level 1 Slowness toolbox, and proceeded to show me how to use it. I thanked her profusely, and the call came to an end when client 1 finally came back on the phone to verify that things were working to their satisfaction. After entering my notes on that ticket, I remoted into the other client's server, and ran the toolkit. The changes it made would require a reboot (to be performed by our after-hours folks) and follow up the next day to see if the fix worked. As you might guess, the kit worked like a charm.
