Image Image member login  |  privacy policy  |  contact us
      Home  |  FAQ  |  Awards  |  Reports  |  Library  |  Jobs  |  Consultants  |  Join  |  Order
   Inside
Library index

The ASP Library contains reports and articles of interest to tech support managers. We're actively looking for additional articles;
if you'd like to contribute, please drop a note about your proposed topic to ASP executive director
Jeffrey Tarter.
     ASPonline.com  >  Library  >  Web Support >


Should you upgrade your support tools?

By Françoise Tourniaire


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

So, you read the support press. You go to support conferences. You talk to other support executives. You see the slick demos, you read the temptingly short ROI analyses. Should you take the plunge?

Not necessarily. Selecting and implementing a new support tool takes lots of time and resources, even if you do it right and even if you have fairly modest goals. 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, don't expect that a tracking tool will magically make those groups more responsive. If no one is tasked with creating knowledge base documents, they will not write themselves.

If you have process issues, address them first before 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 tracking 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? Not necessarily, it could be a bad customization rather than a weakness of the tool itself.

If you have trouble separating customization issues from issues with the tool itself, a short consultation with the tool vendor may be required. A small fee for a couple days' investigation could be the best investment you can make.

It could be that the customizations are poor because the tool offers weak customization tools. That in itself could be a good reason for you to find a tool that's easier to work with from a developer's perspective.

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

Are users saying that the tool is too slow? Start by defining 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 five 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, or as a second opinion.

Some performance problems are related to the way the tool is customized. 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.

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

Start by checking whether the information your staffers need exists and is reliable. For example, you can't expect 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. Is the information stored in another, inaccessible tool? Investigate ways for support staffers to access that tool. You may need a full-blown (and costly) integration between the tools, but perhaps a simple lookup would be enough. Don't overbuild.

Is the information missing because it has no home within the tool? Adding appropriate fields may be pretty simple. If not, a new tool may be required.

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

Many tools don't make it easy to create tailored metrics. If your problems are purely around metrics, investigate purchasing 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.

Also, 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: Are you ready to invest in a replacement?

Implementing a new support-tracking tool will take a minimum of three to 12 months, and that's in addition to the weeks or months you will need to select the right tool. Do you have the stamina and resources to get it done? If you have any doubt, stick with what you have and focus on other issues. Support organizations can get buried in tool implementation projects unless they have a dedicated champion, a reasonable timeframe, and an adequate budget.

If all the questions above point to a new tool, start shopping. We'll provide selection and implementation tips in future articles.


Françoise 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/justenough.html. You can contact her at 650/559-9826 or FT@ftworks.com.