Systematizing User Support

When I started this "Help-Desk" series I wrote: "A great step forward for your informal user support desk is to provide them with a few procedures and tools that can help them be effective and efficient in this function." But so far all I've talked about is the toolkit: putting a ticketing system in place. What about those improved procedures? Actually, for our little company developing a ticketing system proved to be the key to process improvement: the system made it easier for us to describe, refine, and enforce our approach to support. Turns out it's easier to think calmly and rationally about tickets than about this crisis or that. The key was the Status field in each the ticket. I know this sounds obvious, but it took us a while to realize it: giving each ticket a well-defined status makes the status if each ticket clear. So as we have made improvements in our process, we've added, removed, or renamed statuses, and made changes to the rules governing status change. In the early days of our company, we had a customer support process that Jochen Heyland, our CTO, jokingly describes like this. "When a ticket comes in, determine if it is urgent or not. If it is urgent, panic. Drop everything else and address it immediately. If it is not urgent, just forget about it." I still see this panic-driven approach in play at numerous small non-profits. It arises when no other process is defined and you need to think about how to handle each request as it comes over the transom. How do you improve this? We've moved to a system where any defect reported by a user -- if all goes well -- will pass through 9 statuses. These are Submitted, In review, Approved for action, In progress, Ready to test, In testing, Ready to install, Client testing, Completed. We will also decide if it has Urgent or Normal priority. You might come up with a different process path. That's fine. But having clear terminology for each step helps make the entire process repeatable and controllable. For example, we used to mark an item Completed once we'd tested it and made it available to the user. But we realized that at that point we were still waiting for the user's final words that a problem had indeed been corrected. So we added the Client Testing status. When items languish in this status for too long, we can take action - like calling to see if the problem has indeed been corrected. You also need to define the steps on various side paths. For example a defect report might end up with the status Cannot Replicate. Or a request for consultation or training might need to go through Needs Estimate, Estimate Ready, Estimate Pending Client Approval before it gets to Approved. With this in place, a great deal of your internal administrative work can be accomplished just by calling up a list of items with a particular status. You can sit down as a team and do this. Check what is in progress and see how they are coming along. See what has been approved but not tackled yet -- and find out why. Look for items witht he priority urgent and make sure they jump to the top of the queue. Voila: Order out of chaos.