I am trying to figure out the best way to identify, by product, the
prioritized list of issues that result in calls into our customer
support organization, the "top issues list". This list would then be
used by Engineering to help us direct our maintenance efforts to the
areas of the product that will provide the biggest impact.

It sounds like a straightforward thing to do, but it is proving very
difficult to get data categorized in a way that provides a meaningful
"top issues list". Ideally we would have a list that told us things
like "issue x is causing this many calls and costing us $y per month in
Support costs". One of the problems is getting these lists to be at the
right level of detail, we need them to be detailed enough that we can
work on a solution, but not so general as to be meaningless (for
example it doesn't help to say something like "30% of calls are related
to install").

I see this initially as a categorization problem, i.e. we need to
define a meaningful breakdown of the application functionality, along
with behavioral and other attributes. Then we need people trained on
using this and have to roll it out across different functions and
tools. With this model in place we'll have a framework within which to
create the "top issues list".

How have other people/companies solved this problem and how successful
have those solutions been?

Thanks in advance for any comments on this.

Paul.

Responding to Phemson...


As I am sure you realize, the cost of support is orthogonal to
categorizing calls. Figure out what the relevant categories should be
and then worry about about how you track costs for them.

If you want to include diagnose & repair costs by Engineering as well as
direct Customer Support costs, you will probably find those groups will
want a different set of categories (e.g., customer perception vs.
software component). Similarly, Marketing might want a product-based
categorization.

So I don't see any universal set of categories working in such
situations. If you have multiple stakeholders, then I would suggest
multiple suites of categories where each class of stakeholder provides
they own suite of categories and their own expert to provide the
categorization.

For example, I once worked at a shop where a Call was handled as a pure
Customer Support activity. A Call might or might not generate an SPR
for a change to the software. The CS people categorized Calls and
Engineering categorized SPRs. If an SPR was generated from a Call, the
Call ID was part of the SPR, so one one have a means of correlation.
The relevant product category was provided for both Calls and SPRs but
Engineering had the final word when both were generated (after diagnosis).

What the categories should be is really a local option issue. It will
probably vary a lot from shop to shop even for the same general sorts of
products. IMO, the primary stakeholder should define the categories.
For example, CS people should have the best feeling for what call topics
are useful from the customers' perspective while Engineering should have
the best handle on what sorts of things go wrong in the bowels of the
software. IOW, put the relevant stakeholders in a room and don't let
them out until they come up with a list they can all live with.

FWIW, if there are a lot of categories for any given group, I would try
to find a multi-tier classification where there is a smallish set of
broad primary categories and one then also picks a subcategory from a
limited selection for each specific primary category. This tends to
make data entry easier and it is often easier to define and learn
because one has combinatorial classification with a relatively small
number of choices.


The first sentence makes me a little nervous because it conjures up an
image of a gazillion categories trying to serve a lot of different
masters. I would be inclined to identify different goals for the
categorization and then develop separate sets of categories tailored to
each specific goal rather than trying to tie them all together. Then
only certain experts deal with each goal context. That makes training
and whatnot a whole lot easier.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH