The Getting Things Done movement has gained a lot of traction with the lifehacking crowd on the Internet. Created by David Allen, GTD is built around the idea that by creating simple action plans for the tasks that we have to accomplish, we can create efficiencies that will leave us more time for the things we want to accomplish. Allen's original plan of action has inspired a large community that has adapted and extended his principles. At the forefront of this movement is Merlin Mann, creator of the GTD site 43 Folders.
Merlin was invited in July to present a Tech Talk to Google staff on Inbox Zero, his personal refinement that applies some GTD concepts in order to manage e-mail effectively. I thought that his presentation offered a lot of great advice for those people who are struggling with a large volume of e-mail, but its value needn't stop at the inbox. Help desk pros have to manage another stack of incoming messages apart from e-mail; there's the trouble ticket queue as well. Every office has some way of requesting tech support, whether it's a fancy Web-based ticketing system, a call center, or simply e-mailing the guy in the basement office. Whatever way they're submitted, these requests end up in a list that the help desk has to work through. Inbox Zero is all about working through accumulated messages, and we can adapt some of Merlin's e-mail tactics to the list of requests that make up our support queues.
Merlin says something in his presentation that brought a wry smile to my face. He states (and I'm paraphrasing) that an individual's time and attention are both finite resources, and if left unchecked the demands that are placed on those resources could be infinite. I've felt that way; I'm sure that every help desk pro has at times. There are some days where I've spent all my time acknowledging requests and no time actually solving the problems that prompted them. It's during those busy periods that having a process for effectively managing the request list can help protect the time and attention that support pros need to solve problems. That's the appeal for me of adapting Inbox Zero to my trouble ticket queue.
Here are the ground rules I've decided to abide by as I try and implement "Queue Zero":
- Don't get hung up on the medium. Whatever form it takes, your support queue is just that, a medium. A fancy request system won't make your help desk serve customers better. If your help desk establishes a work flow that is repeatable and clear, the medium doesn't matter so much.
- Convert requests to action. This is the heart of effectively processing requests. Define a set of actions that can be applied to incoming requests. The set should be clear and as small as possible. Then, when a new request comes in, choose the appropriate action, and do it.
- Process the queue to Zero — every time. This doesn't mean that when you sit down to manage the requests that you have to instantaneously solve every problem. But each time you look at the queue, each request should be acted on. Nothing should be left untouched.
The fundamental piece of wisdom that floats to the surface as we map Inbox Zero onto the help desk is that the important work happens away from the queue. The most important task that support pros have is actively solving problems for clients, and the workflow of the help desk should enable that. The Inbox Zero work flow for e-mail is about processing incoming messages to clear actions; Queue Zero is about doing the same for incoming support requests. Here are the verbs that I'm trying to use to process the tickets that I have coming in:
- Respond. Maybe I need more information about the problem, or maybe the question is something that can be quickly answered with a web or knowledge base search. I use this when a quick e-mail or phone call to the client will solve the problem. Or when an emergency arises that needs immediate attention.
- Delegate. Maybe this is a task for a lower level tech to handle, or something that should be referred to operations. In my personal case, I'll often encounter a question that would be better answered by one of the programmers we have on staff. If you delegate a task though, remember to follow up and make sure it got done.
- Defer. This is for problems that require research, or long-term projects. If I defer a request that means it's not something that I can quickly solve (or its not urgent). This is also the verb I use when I'm waiting on a response from someone else, say if a part is shipping from an OEM. Deferred tasks are scheduled for follow-up during the time I'm not out on support calls.
- Act. If a ticket requires a site visit, for example, I'll schedule it with the user. If I need to order a new machine, I'll do so. Right then.
In the work flow I'm testing right now, when I process the request queue each new ticket will be acted on in one of those four ways. Since requests never sit for long without some sort of follow up, I've found that I'm less concerned about the state of the queue at any one time. I don't feel like I have to watch out for an emergency that might blow up. I've been able to get in the habit of processing three times a day: first thing in the morning, at midday, and immediately before leaving for home. By processing the queue to zero during each of these visits and having a clear picture of the actions I can take for each new ticket, I'm spending less time planning...or planning to plan. I have a better handle on my time, and tickets are getting closed sooner than they were when I was letting my ticket queue manage me.