Techsupport Automation


For my first real IT job, I found myself working as a tier II tech for an internet service provider. I had just been freshly certified for A+ and Net+, and taken an introductory programming class, I felt very confident starting this job and looked forward to a bright career in tech. For the first few months it was great, I wasn’t really learning anything new, but was getting to apply the skills learned for my certifications.

Once the “new-ness” of working in the industry wore off (prior to this I was in food-service, leaving that for tech is a huge breath of fresh air), I found myself bored at work, doing the same thing for each caller over and over again. Most of our customers were rural and received internet from us wirelessly. To check on a customers internet connection I had to first look them up in our billing platform (, confirm customer’s information, then take the account number in billing software, go to another website (this site the company developed and hosted for field techs) search the customer’s account number in order to get their wireless radio and router information. Further still, I needed to login to each radio and router to diagnose the issue. That’s four different websites that need to be visited just to see what might be wrong with a customer.

I thought myself fast with a keyboard, and regularly utalize keybaord shortcuts everywhere. My average call time per customer was 7-8 minutes, most of that time was spent waiting on websites to load. The company expected us to have an average of 7 minutes per call, they were ok with us being close and pushed us to break below 7 minutes, but most of the team and I could never get below the 7 minute mark, ever. I began to feel defeated and worthless each time my managers pointed that out in our reviews. I knew this couldn’t be right and something had to change, I decided to expand my development skills by automating a portion of my job.

I started out researching windows automation tools, realized I was overthinking the problem while reading a vaguely related stackoverflow post and heard about browser automation. At first I thought I’d just be clever and use curl to get the information I needed from the various sites I needed to visit. This was ok for the internal tech site…but billing system and anything else I had to log into became more challenging handling cookies and maintaining authentication. To top it off, our billing system and newest (at the time) routers web ui was all drawn in with JavaScript, so my curl requests to these sites were vastly different than a browsers view, I couldn’t even get the proper HTML in most cases. Trying to get around this JavaScript DOM was about to kill my project. I even recall thinking to myself “Maybe this is why it wasn’t done already? Maybe this can’t be done?”

Selenium came in to the rescue, don’t recall exactly how I found it, might have been through “Automate the Boring Stuff With Python”. However I originally found it, it saved the whole idea. I was able to watch selenium manipulate my browser live, and running it with a GUI did exponentially speed up my testing process as I could literally see in code and the site what went wrong and why. While the GUI was fast, far faster than any person ever could be, headless chrome was even faster. Using the GUI I got my average call time down to the upper 5 minute range, the headless version got my average call time down to lower to mid 4 minute range. I was estatic, with my little script, a customer would call in, I’d find their account in the billing system, and put their account number in as the arguement for the script. Script would then go out and find all the relevant information for me, and present it to me in the console. I could then choose to reboot their equipment or exit the script, and exiting the script would put all the connection information on the clipboard. So if I needed to create a ticket for a field tech to go out, I could just paste it in and over half of my ticket information was filled out for me.

My managers didn’t really care though. The only change I saw from them was that my call times weren’t brought up in reviews anymore. I even thought I might get promoted into a dev role (we had one dev at the time) or paid for this script and brought it up in one of the meetings. However they were going through a managerial shift at the time for the call center. The shift wasn’t going on when the meeting occured but was planned. I was told they would “think about it” and “get back to me soon”. Never heard about it from those managers again. Life went on, new managers came in, got situated and comfortable. I brought up the script again, because at this point, me and a few of the more competent techs were actively using the script on every call. Our stats clearly reflected this and the field techs were pleased our tickets came out in one format, easy to read and had all the information they would need. I was told the same thing, “we’ll think about it and let you know”. Never heard about it again, nor did I bring it up again.

Ultimately I left that job because they became unwilling to work with my school schedule. Writing the script was my first real concept to reality coding project. Looking back on it now, it’s horrendous, some ok coding practice mixed in with horrible practice, I didn’t even write a README for the project. The tool worked, and worked effectively, perfect for enterprise.

In reality, I shouldn’t have been able to develop this script in the first place. I ran it from my work computer, a self compiled .exe file from an unpublished author was allowed to run on a company computer, and I wasn’t a local or domain administrator either. Work PC security was lacking to say the best, but it allowed me to complete this project and use it to great effectiveness. I ended up learning a lot about HTTP and how the web works as a whole while creating this. Feel free to read over the repo here and have yourself a good laugh, or cringe reading that code. Rereading a repo I authored 4 years ago leaves me with a mixed bag of both.

Enter your instance's address