Minimal Hardware Required (a continuation of the original post “Wrangling Tech Support Requests for Free“)

I build my Spiceworks helpdesk in a small virtual machine with very little resources. The VM was a Windows XP Pro OS with 1 GB of memory and a 20 GB hard drive. I installed the Spiceworks software and configured it to pull in email from a tech support email box that was already in use for support requests. Spicworks pulled in all the messages that were already in the inbox of that mailbox and made them into helpdesk tickets. From that point I was able to reply to uses straight from the helpdesk software by updating their tickets. Because the software was web-based I did not have to install a client on my computer or log into the virtual machine directly to use it. I created a internal DNS entry for the Virtual Machine (A Record = helpdesk.mydomain.com) and started using the system. Because my users already knew to use the tech support email address, I didn’t have to re-train them on how to submit requests. I was able to basically forget about the management of the ticketing system and just start using it.

This is where the magic began. With the system setup, I began using it daily. Tracking support requests got a lot easier and fewer things got dropped. I started telling end users that submitting a ticket was the best way to guarantee follow through. I promised them that if they submitted a ticket it would only get closed when the issue was resolved. And, most of the time when I did get stopped in the hall, I would make the user submit a ticket anyway, even if I was able to solve the problem on the spot. Now most of my end users submit a ticket first for any requests.

At this point you might ask “So, what has this done for me that I wasn’t already getting with a tech support email box?”. Let me start with the end users. They get an email from the system any time a ticket is worked on with updated notes. Also, when I call them to fix one issue I usually remind them of the other requests that they have submitted and offer to fix all of them at the same time. They like this. I have an assistant, volunteers and consultants so when I need to delegate part of a ticket to a third party the end user is able to see all the communication via email.

On my end, I gained a lot. Because the system emails all “Support Technicians” whenever a new ticket is generated. Me and my assistant both get email alerts when a new support request is issued. Either one of us can rely to the end user from our email accounts (our phones) and it appears to the end user as if it came from the ticketing system. Plus, our replies are documented on the ticket. I can easily track time spent on a ticket, add internal notes, assign a ticket to another technician and carbon copy a third party. The carbon copy feature is especially useful for delegation to consultants. For example, when an internal office requests a new Ethernet drop I used to call the phone company to run the line. Now I add the phone company’s email to the CC field on the ticket and add a note for the phone company. Someone at the phone company gets the email and replies with a date/time that a tech will be on-site. Without having to do anything else, the end user is notified and the all correspondence is documented in one place. When the work is done I close the ticket. The closed tickets can be referenced at anytime.

So, lets recap. I have a free method to centrally manage support requests that allows me to:

  • Keep end users, assistants, volunteers and consultants all in the loop together
  • Easily document issues and track time spent on issues
  • A historical and complete record of resolved issues that can reference as needed

all for free. Sound good! But, like they say on infomercials “wait there’s more!”.  To find out about some of the unexpected gains I got from this system check back for a future post.

Menu