RE: Documentation and Bug Reports

["Gururaj B S" <gururaj_bs -at- hotmail -dot- com>]

> Goldstein, Dan wrote:
> > Years ago, at a meeting with a company exec who hired our
> firm, he told us
> > that the goal for our documentation was to reduce the calls
> to their Help
> > desk by 20%. I don't know how they planned to measure that,
> if they really
> > measured it, or what the final number was.

> Reducing support costs should always be a documentation goal.
> In theory, if one does a
> perfect job, the other is totally unnecessary! But this sort
> of thing *is* hard to
> quantify. And few pubs managers seem to think about it. The
> only time it was ever an issue
> for me was when I working *for* the customer service
> department. And come to think of it,
> a lot of what I wrote should have been written by the regular
> tech pubs people.


<<Gururaj

I think it depends on the support channel of your organization. Managerial
wisdom has it that a technical writer is an epitome of end-user experience,
and he or she has to look at a product being developed from a supportability
point of view. Here's how a customer's call is usually routed to the
software/hardware maintenance folks.

Response centers (call centers, in other words) --> technology group
(technical support) ---> maintenance groups (research and development wing
of the organization)

The call centre professionals usually do not have a very good knowledge of
the product being supported. Their key focus is on interpreting the
fundamental aspects of the problem in terms of technical language. They
enable the technical support professionals to analyze the problem;
nonetheless, if these folks are in a position to analyze and resolve a
technical problem, the technical support folks (with higher knowledge of the
product/domain) need not be concerned with those basic problems. How do they
learn about a particular product? No doubt about it! They read our user
guides and other support manuals to learn about a new product. When a
technical writer writes documentation, he or she should take care of this
aspect as well.

I recommend that you do a few things here.

* Firstly, make them read your documentation when supporting a particular
product or customer.
* Get input from them on the nature of problems reported by your customers.
It helps.
* Try to involve them in all rounds of review. Let them comment on the
usability/supportability coverage of the product in documentation.
* Interact with them as frequently as possible. Try to fathom what the
customer thinks about your documentation.

If your documentation is consummate, these call centre folks will be able to
resolve a problem themselves. The cal may not be forwarded to the next stage
of the support process. The support costs will reduce if your documentation
eliminates the need for a higher escalation. If it reaches the maintenance
level, you are forced to ship a site-specific or general patch to your
customers, which requires a lot of resources and efforts.

The number of customer calls tells you how good your product is. It also
gives you an idea about how user-friendly your documentation is.

Cheers
Gururaj
---