Re: Teach an old listmember a new trick-Customer Service documentation...

[Dan Brinegar <vr2link -at- VR2LINK -dot- COM>]

Heyya Lisa, welcome back!

(I'm back too...  [the crowd groan] ;-)

>"What does technical writing have to do with Customer Service?" You ask.
>"That's what I'm trying to find out." I wittily reply.

Well, good docs for the Customer Service Snuffys can help quite a bit when
they're dealing with a customer; good techsupport docs can help the bobs on
the phones; and good help/manuals/built-in performance support for the
product can reduce the frustration end-users may encounter.


That's assuming everyone in that chain *uses* what the technical
communicators provide...


[NOTE: Assumptions I make about what everybody can understand in the
following may not be clear: sorry. When I say "Company" one may assume I
also mean "Gov't Organization" unless stated otherwise, and unless
"everybody knows" Gov't organizations don't work that way. One may also
assume that a "smiley" emoticon < 8-) > exists at the end of each chunk of
text unless otherwise specified. Box art shows assembled and painted model.
Time travel to correct past mistakes is no guarantee that the timeline
created by that mistake will not continue anyway. A nice tie is often a
better way to send a message than a cruise missile. OAC HAND]

One of my Rules has always been "If your customers are idiots, you're not
doing your job" and for the most part it's true: T/Cs should be advocates
for the customer at every point in the development process they can get
their hands on; whether that involves ranting in the snack room, taking the
staff to a users' meeting on Saturday or using the time your Boss planned
to spend chewing you out for throwing the phone after a tough service call
to evangelize the need for better documentation and performance support.

We're not providing customers a service just so they'll give us money:
they're giving us money to provide a service; they expect everything to
work or we have to fix it.

Unhappy customers sometimes show up in newsgroups, on CNBC, at
shareholder's meetings and/or outside Government House with torches and
farm implements... Remember that Microsoft, McDonalds and Japan are *not*
too big to fail -- it just takes longer, and catches everyone by surprise.

Unfortunately, no amount of documentation will help if a customer who's
never even whittled gets sold a 12-axis Thermo-Plutonic Ethereal Machining
Center and can't understand the safety warnings on the first page of the
manual. The company's responsibility in that case is to provide a
completely intuitive product, extensive hands-on training, or the
customer's money back -- otherwise it's just fraud -- and the fact that the
customer is widely considered an idiot is not *entirely* your fault, so
don't become frozen by guilt and then let the situation become a complete
crisis for the customer *and* the company.

> By anticipation of user
>questions, concerns, and problems , creation of documentation for these
>situations, and easy access to this information, we have created a sense of
>confidence.

You must be able to work this into a product lifecycle -- make it an
ongoing process -- rather than a one-time event ("you" in this case being
both you-the-TC and You-The-Company/Organization). Follow up with whatever
you can glean from the customer service reps and the support bobs so you
can improve the docs... or provide a process whereby they themselves can
update the docs (be those docs FAQs, support-scripts, reference-cards,
whatever).

After you've improved the docs often enough, you *will* have the data
needed to make real customer-focused improvements in the product/service
itself.

For what it's worth (less than $0.02 or .1627 euro at current market price)
you can skip the rest if you like --  ;-)

<anecdote>
Dear Very Big Boss,

I have received yet another email from CustomerX  asking that I call and
explain <font> tags in HTML.

* Page One of my manual states very clearly IN BOLD RED LETTERS that our
product is designed for EXPERIENCED WEBMASTERS.

* We have to date expended the equivalent of $36,000 in shop time
supporting CustomerX.

* Our product costs $400.

* For $36,000, you could have hired another bob for TechSupport *and* paid
me to write a 500-page book on every-step-required to use our product
starting with "Sit down (in a chair) and turn on your computer..."

* I would suggest/must insist that instead of charging CustomerX $75 for
every service call, we give CustomerX his $400 back and dock the
salesdroids who made the sale until they tell potential customers the truth
that they (or their webmaster) *MUST* understand web development beyond
what the ads for the common web development tools say can be done with them.

</anecdote>

>Hello all! I have been on hiatus from the list, and the working world for a
>few months, but I am back, and ready to stir up trouble! :) (Just kidding,
>although I'm sure this post may garner me some flamage...they usually do.)
>
> We are trying to
>(among several other things) increase the level of client service (client
>meaning end-user) during this project, which will (hopefully) continue on
>even when this project has been completed.
>
>Since I have (in a way) become the poster child for documentation on the
>team (must be my love of words and anal retentive AKA organized habits), I
>have decided that documentation can become a great tool for customer
>service.




-----------------------------------------------------------
Dan BRINEGAR,  Info Developer/Research Droid
CCDB Vr2Link Performance S u p p o r t Svcs.

<mailto: vr2link -at- vr2link -dot- com>
http://www.vr2link.com

"Is it 'freedom' if you're in a cage too big to fly across?"
   -- Anson Guthrie, as reported by Poul Anderson


 From ??? -at- ??? Sun Jan 00 00:00:00 0000=