TW and Tech support

[Katherin King <kking -at- BROOKTROUT -dot- COM>]

I find this a very interesting problem, because if the documentation is
fuzzy, users will call tech support for clarification. If we can assess
where they are having problems, we can improve the documentation.

We have several methods of involving tech support:

*       Weekly developer meetings, which includes not just developers,
but also QA, documentation, and tech support. The purpose of the meeting
is to fill everyone in on what everyone else is doing, since we are all
intertwined. If I hear that tech support has a problem with a customer,
I can determine whether it's a doc issue or not.
*       Every piece of documentation I write goes to tech support, QA,
and the supporting software engineer for review, as a minimum. I get A
LOT of good feedback from tech support, because they know that the
clearer it is to the user, the fewer calls they'll get.
*       We use bug tracker software which includes doc "bugs" as well as
software bugs. In other words, if anyone finds something fuzzy, missing,
or wrong in the documentation, it's entered into the tracker database,
assigned to me, and it becomes my responsibility to fix it.

Work hard on developing a good relationship with tech support. They are
an invaluable resource for tech writers.


Kathy King
Documentation
kking -at- brooktrout -dot- com


Posts: mailto:techwr-l -at- listserv -dot- okstate -dot- edu
Commands: mailto:listserv -at- listserv -dot- okstate -dot- edu (e.g. SIGNOFF TECHWR-L)
Archives: http://listserv.okstate.edu/archives/techwr-l.html,
	http://www.documentation.com/, or http://www.dejanews.com/
Subjects: JOB:, QUESTION:, SUMMARY:, ANNOUNCE:, or none of these.