Help for the Helpers

This post was originally published on the Idealware Blog in January of 2009.

If you’re in a job that involves supporting technology in any fashion, from web designer to CIO, then the odds are that you do help desk. Formally or not, people come to you with the questions, the “how do I attach a file to my email?”, the “what can I do? My screen is frozen”, the “I saved my document but I don’t know where”. Rank doesn’t spare you; openly admitting that you can do anything well with computers is equivalent to lifetime membership in the tech support club.

A full time tech support job is, for the most part, an extended roller coaster ride with more down slopes than up. People who are drawn to this work are generally sharp, eager to assist, and take pride in their ability to debug. The down side is that, day after day, it’s grueling. There’s always a percentage of people who would just as soon smash the machine and go back to their trusty Selectrics. They aren’t always happy or polite with the friendly tech who comes to help them.

But the most debilitating aspect of the work is that support techs don’t manage their workload. It’s randomly and recklessly assigned by the varying needs of their co-workers and the stability of their systems. They never know when they’re going to walk in the office to find the donor database is crashed, or the internet line is down. The emails come in, the phone rings, and, to the people calling, everything is a crisis. Or it certainly seems that way. The end result is that career support techs often develop a sense of powerlessness in their work, and the longer it goes on, the less able they are to take proactive action and control of their jobs.

So here are two complimentary actions that can be taken to brighten the life and lighten the load of the support tech.

1. Deploy a trouble ticket system. And make sure that it meets these specifications:

  • Incredibly easy for staff to use. Web-based, linked from their desktop, with, ideally, three fields: Name, priority and problem. The software has to be able to grab additional information automatically, such as the time that the ticket was submitted, and, optimally, the user’s department, location and title, but the key point is that people won’t use the system if the system is too annoying to use.
  • Every update is automatically emailed to the user and the tech. This is critical. What an automated trouble ticket does best is to inform the customer that their issues are being addressed. Without this communication in place, what stands out in user’s minds are the tickets that haven’t been resolved. Confirmations of the fixes, sent as they occur, validate the high rate of responsiveness that most help desks maintain.
  • Be clear that the scope of the problem will influence the response time. Fixes that require spending or input from multiple parties are not slam dunks. This communication might warrant additional checkboxes on the submission form for “requires budget” or “requires additional approvals”, but formalizing this information helps the customer know that their issue hasn’t just been dropped by the tech.
  • Have a default technical staff view that puts open tickets on top. In environments where the telephone is the primary support funnel, things get forgotten, no matter how good and organized the tech is.

There’s more to it – good ticket systems feed into, and include links to additional support resources. And they don’t replace the telephone – IT has to be readily available. But there should be an understanding that users follow up phone calls with tickets. These are the key strategies that help the seemingly unmanageable stream of support calls fall in line.

2. Allow the support staff to breathe. There has to be an understanding, primarily understood by the support tech, but reinforced by his or her manager, teammates and staff, that only emergencies demand emergency response times. In fact, treating every call as an equally important, must be fixed immediately situation is a strategy for failure. Support Techs need to do effective triage, and put aside time to analyze and act proactively to solve user problems. If they deal with the same questions over and over, they have to write and publish the solutions. If the calls indicate a common problem that can be solved with a better application or an upgrade, they need to be able to step back and assess that. Smart managers will enforce this measured approach. At first, it will go against the grain of service-oriented staff, but it’s a must, because the measured response begets the more comprehensive solution to any problem.

Comments are closed.