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 directorJeffrey Tarter.

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.