Begin with a Story
Once upon a time, we ran a full-service broadband wireless ISP. We built it from the ground up, starting from the day of providing dialup internet. We ran scripts on the terminal command line when we needed to create a new account or an email address, and we pretty much knew all the customers. As we grew and added staff, there became too many customers for all of us to know, but every customer was known by name to at least two or three people in the company. This was great, but because a different person might respond to fix an issue that any given customer was having, we needed a central place to track the history of technical issues a customer might be having. This would mean that not only would a technician not have to investigate every issue as new, it also meant we could spot trends and recurring issues to be able to deal with them more proactively. It mean that if something had been tried and only worked for a week or so, the next technician would know to try something different.
Such systems exist and are well-known in the telecom and technology industries as well as in enterprise environments where the IT department is dealing with hundreds of computers. Even so, we wrote our own system, from scratch. (Did I mention we’ve also got a strong history in software development?) The system was built using Perl, MySQL, and some PHP, and of course, it had a web browser interface so we could even use it in the field and didn’t have to install it on multiple devices. It used a Perl framework for rapid development called DBI-Quick, which was also entirely written from scratch by Scott Toderash. We wanted our system to not only be a knowledge base of past issues and how to fix them, we also wanted it to monitor devices in the field, to connect to them and manage them or check statistics, enable and disable client devices, and create a graph of particular statistics over time. We also wanted it to connect with the billing system and perform all the functions of a full-scale CRM, which we did build out, along with geomapping of customer addresses and location coordinates with Google Maps integrations to deal with a largely rural customer base — but we’re getting beyond the point of the story.
Our system could track issues and keep track of notes and updates for each one, assigning (or reassigning) them to specific technicians, and marking their status, such as “open” or “closed”. We could view all tickets for a given customer and see the ticket history, and we could see all the open tickets at any given time. This made everything so much more efficient for running the operation, helping us to keep track of things and make sure each issue was prioritized and dealt with in turn.
When we started 100% Webhost (100% Helpdesk), we wanted the same benefits, but we didn’t need to deal with the same kind of field equipment, so our requirements list was much shorter, and we implemented an open source ticket system where we can not only create tickets manually, but more importantly, they can be created automatically. When people email our support address, a ticket and an autoresponse with the ticket number is automatically generated. When anyone leaves a voicemail in our support inbox, it is transcribed to text and along with the audio message, attached to a newly-created ticket. Our various hosting systems can also create tickets automatically so we can easily review or confirm particular events or trends on those systems.
Tickets at Modern Earth
It’s not that other agencies don’t use such systems; some do, some don’t, some are in-between somewhere. Prior to our acquisition of the company, Modern Earth used a different form of issue-tracking system, which has been replaced with the one we’ve been using for the past ten years. As we’ve used it, we have added some custom reporting functions, particular configurations and upgrades along the way, and we believe the system to be extremely robust, helping us through each day more efficiently. Let it be said that Ryan Schultz is the master of this ticket system. Modern Earth is not our first acquisition, and as we’ve brought clients and services onboard from a variety of other systems, Ryan’s most famous comment was “I didn’t realize how good I had it!” The system works.
What’s the point of all this? It comes from a customer concern: when we explained how he should contact us to get the quickest response, he had quite a negative response to ticket systems in general. It turns out that many people associate being given a ticket number with being dehumanized to the number and being forced to deal with someone in a call center overseas somewhere who, when asked where they are located, will produce a just-audible sound of paper shuffling and respond with the name of some American city, sometimes mispronouncing it.
So now we get the hesitancy, and understand if there’s an eye-roll involved. We just want to set the record straight and give you the three main reasons we use an issue tracking system.
1. Historical Record
When issues or other requests go through our tracking system, we’re able to build a historical record for their account. Time is tracked on these issues, whether it’s billable or not. If a customer tells us they’ve had this issue before, we can look back and see how it was resolved. If a customer has an issue that we know is similar to one experienced by a different customer, we can look that up as well, so we can resolve issues more quickly. When we resolve an issue, we document how it was done, turning the record into a knowledge base that can save time for us later on down the road.
2. Accountability
Each ticket is assigned to a person to be responsible for it and update it’s progress through to its resolution. If the issue is something that we would invoice for, there is an accurate record of how many minutes were spent on which tasks by which technician, and this is reviewed before any invoicing occurs. If a ticket remains open for too long, our system includes an escalation procedure — not only can it remind someone that they have an outstanding issue to resolve, if it’s an important one, it can also notify another technician or supervisor to check in and see why it’s still outstanding.
3. Efficient Issue Response
When you email our support system, you are not emailing a specific individual, and this is where the disconnect comes in for many people. They want to know that some specific person with a name is handling their issue, and they know who to follow up with. On the surface, this makes sense, but there’s a practical issue at play: what if the person you emailed is not available before you need your issue resolved, website updated, or other response? In smaller companies, that’s just the way it goes, but with more people available to assist (and an account history to help them do so), someone else can always step in where necessary to make sure things are responded to in a timely manner, even if it’s simply because one person is too busy on a given day while another can fit the task into their schedule. Very often the ticket is assigned to the person you may have emailed directly, and that’s who you’ll hear from. Sometimes the issue is better dealt with by a different individual, and your request is redirected, so for example, technicians are fixing email rather than designers.
The Bottom Line
We always prefer requests be created or issues be reported by emailing , for all of the reasons above. You can, of course, email an individual, but in most cases your email is going to be copied into our ticket system to ensure the above objectives are met. We’ll still deal with you by name, one person to another. The ticket number itself is more for the database to track and match things; to be honest, we hardly even look at it.
Our helpdesk is not outsourced, since it’s integral to our model of client care, and is one of our unique selling propositions for 100% Webhost. We’re still catching up with getting to know some of our new clients (and seriously loving this part) following the Modern Earth acquisition, but know that someone in our company (we’re not that big) knows your name and the history of your account. We’re continuing to document and flesh these histories out, but once again, this is an inherent part of our client-care model.
