Is your support-tracking tool ancient? Slower than molasses? Does it require an assortment of technical gurus to keep it running, with additional, expensive resources required for any upgrades or changes? Are metrics a rare luxury that requires more specialists, so much so that you have given up doing any kind of ad-hoc analysis?

Meanwhile, you read the support press. You go to support conferences. You talk to other support executive. So you have seen the slick demos, read the temptingly short ROI analyses, perhaps got an earful from a satisfied and boasting-prone colleague. Should you take the plunge and get another tool?

Not necessarily. Selecting and implementing a new support tool takes lots of time and lots of resources, even if you do it right, and even if you have fairly modest goals, so before you make a move you owe it to yourself – and your favorite CFO – to take a good, honest look at the tool you have, and where your problems come from.

Question #1: Could the problems be caused by a poor process?

Many times, problems that are blamed on the tool actually stem from process issues. For instance, if the process for resolving cases is unclear, support staffers will struggle to shepherd issues to resolution. If you don’t have agreements in place with Engineering, Repair, or other groups you depend on to resolve certain issues, no tool will magically make those groups more responsive. If no one is tasked with creating knowledge base documents, they will not write themselves automatically.

If you have process issues, address them first before even thinking about changing the tool. Since implementing any new tool requires well-defined processes, the effort will be worthwhile even if you end up deciding you need to change tools. Pay particular attention to transitions between individuals or groups since transitions are where most process problems occur.

Question #2: Is it the tool, or is it the way it's implemented?

If using the tool is about as pleasant as getting a root canal, the tool is bad, right? Wrong, it could well be the way the tool is customized. It can be difficult to separate customization issues from issues with the tool itself, so a short consultation with the tool vendor may be on order. A small fee for a couple days’ investigation may be the best investment you can make.

Question #3: Is the tool struggling under a miserly IT infrastructure?

Are users saying that the tool is too slow? Step one is to define what "too slow" means. Don't bother with fancy benchmarks at first. What really matters is how long it takes the users to accomplish basic tasks. Does it take more than a few seconds to paint a new screen? Does it take more than a minute or two to enter a new case? Does it take more than 5 minutes to create a new user? These benchmark numbers, not technical stuff like the latency on database access are what's important to the support staff.

Determine whether performance problems can be traced to network or server problems. If you have staffers working from home or from small offices, upgrading their network connection is usually your best bet to improve performance. Here again, a short consultation with the vendor may be helpful if your IT staff lacks that kind of expertise.

Some performance problems are related to the particular implementation of the tool. I once worked with a client that required such elaborate root cause categorization that it took several minutes to close each case. Way too long for me! This was a customization issue, not a problem with the tool per se. See question #2, above.

Question #4: Can staffers access the data they need to do their job?

Start by checking whether the information your staffers need exist and is reliable. For example, you can't expect your knowledge base searches to be successful if no one is taking care of the content of the knowledge base in the first place. This is a process issue, not a tool issue (question #1). Is the information stored in another, inaccessible tool? Can support staffers get access to that other tool? Yes, you may need a full-blown (and costly) integration between the tools, but often a simple lookup is enough. Don't overbuild!

Is the information missing because it has no home within the tool? It shouldn't be too hard to add the appropriate fields. If it is too hard, a tool change may be warranted.

Question #5: Do you get the metrics you need?

Most tools don't make it easy to create tailored metrics. If your problems are solely metrics-related, investigate adding a reporting tool to extract data from the support tool rather than automatically thinking of a replacement, which may be no better in the metrics department.

However, most metrics issues are not tools-based but process-based. Have you defined a small, yet comprehensive set of metrics? Is all the data you need reliably collected in the tool? If not, address the process issues before worrying about the tool.

Question #6: Do you need a new tool, or you just want the new, cool technology?

Even support managers can succumb to the lure of new, cool toys. Be honest with yourself: if your support-tracking tool is basically working well for you and your only reason for a change is to be able to brag that you have the latest technology, find another way to satisfy your toy envy and leave your support-tracking tool alone. Cool tools do not.

Still convinced that your tool is weak after going through all 6 questions? You probably need a replacement. Happy shopping.

About the author
Francoise Tourniaire is the founder and principal of FT Works, a consulting firm that helps technology companies create and grow their support operations. She is the author of “Just Enough CRM”, a practical guide to selecting and implementing CRM systems, to be published this month by Prentice Hall. You can find a full description at www.ftworks.com/JustEnoughCRM.htm. You can contact her at 650-559-9826 or FT@ftworks.com.