TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Re: Metrics used to evaluate Technical Writing/Publications
Subject:Re: Metrics used to evaluate Technical Writing/Publications From:Keith Hood <bus -dot- write -at- gmail -dot- com> To:Sion Lane <sion -dot- lane -at- unit4 -dot- com> Date:Mon, 14 Sep 2015 09:43:01 -0500
To open a related can of worms: Find out what foundation documents the
help desk people use in their work. Obviously they read their way through
preset scripts, but the corrective steps they suggest have to be taken from
some source. Is that source the help documents that you prepare? And if
not, why not? Is their stuff more complete or more up to date than yours,
or vice versa? This doesn't have anything to do with metrics per se, but
communicated on this line of inquiry could be quite revealing about changes
that may be needed.
On Mon, Sep 14, 2015 at 4:02 AM, Sion Lane <sion -dot- lane -at- unit4 -dot- com> wrote:
> Will Husa said:
> " I suggest that you speak with your Help Desk. They are on the front line
> for
> complaints. Ask them what your customers are complaining about and then
> create a metric based upon that."
>
> As part of this, ask your helpdesk to include a new question in their
> script "Did you try to solve this issue by checking the documentation?" or
> words to that effect. If the customer has not tried, the helpdesk could try
> and point them in the right direction for future reference; and if they
> have, they should be able to identify why it wasn't helpful.
>
> Spending a day sitting in on support calls can be a great way to identify
> holes in the documentation, and a depressing way to discover that nobody
> actually reads the fm.
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Learn more about Adobe Technical Communication Suite (2015 Release) |
>http://bit.ly/1FR7zNW
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> You are currently subscribed to TECHWR-L as bus -dot- write -at- gmail -dot- com -dot-
>
> To unsubscribe send a blank email to
> techwr-l-leave -at- lists -dot- techwr-l -dot- com
>
>
> Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
>http://www.techwhirl.com/email-discussion-groups/ for more resources and
> info.
>
> Looking for articles on Technical Communications? Head over to our online
> magazine at http://techwhirl.com
>
> Looking for the archived Techwr-l email discussions? Search our public
> email archives @ http://techwr-l.com/archives
>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Learn more about Adobe Technical Communication Suite (2015 Release) | http://bit.ly/1FR7zNW