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.
I will also say the support techs here are always excited when I already
had instructions written for solving a particular issue, and they can
simply direct the customer to it!
On Fri, Sep 26, 2014 at 1:34 PM, Mike Starr <mike -at- writestarr -dot- com> wrote:
> So, maybe instead of RTFM, we should just say RTFD (Read The F***ing
> Documentation) and separate the delivery method from the fact that there
> actually is adequate documentation even if the customer doesn't bother with
> it.Nancy's got a really good point. We do the best we can to provide
> whatever assistance we can to our customers. How we deliver that assistance
> is secondary to actually getting our customers to consult that assistance.
> It doesn't matter whether it's on paper, a PDF, online help or whatever...
> if our customers fail to avail themselves of what we've created for them,
> they're going to pick up the phone.
>
> If enough customers call that a company needs a call center staffed
> 24/7/365 that's an additional expense that we'd like to avoid or at least
> minimize. Some calls can't be resolved by telling the customer to RTFM
> because some products actually have design flaws whether it's software or
> hardware. However, hopefully those calls are a minimum percentage of the
> calls we receive.
>
> But the fact is that in many cases, the vast majority of calls can be
> resolved by getting the customer to RTFM (no matter what delivery method we
> use). No matter how good the FM is or what delivery mechanism we choose,
> it's like pulling teeth to achieve acceptance and use of the FM among the
> customers. You can lead a horse to water but you can't make it drink.
>
> I'd just about finished this screed when I took a look at Tony's
> followup... Tony said:
>
> Customers want out of the box functionality, with some power-user
> customization.
>
> That's fine for one-trick pony products but when the product is an
> incredibly powerful and complex product with a lot of options, it's a whole
> different ball game. Products of that nature require comprehensive
> documentation. You can't just do a quick-reference that tells the customer
> how do do a dozen or so simple procedures. You need to give them reference
> material that explains how the (e.g.) 20 different controls (radio buttons,
> drop-downs, etc.) on a specific dialog box affect how the process they want
> to accomplish is performed... how those variations in control settings
> affect the results. Many will say to simplify the product but if the
> marketplace demands that level of power and complexity (and more
> importantly if the competition is providing it), that's not always a
> workable option. I've worked with products with that level of complexity
> and routinely beaten up the programmers and engineers when there's a better
> way to present options to the customers but even that doesn't always get
> the customer the information they need if they don't consult the
> documentation.
>
> Best Regards,
>
> Mike
> --
> Mike Starr, Writer
> Technical Writer - Online Help Developer - WordPress Websites
> Graphic Designer - Desktop Publisher - Custom Microsoft Word templates
> (262) 694-1028 - mike -at- writestarr -dot- com - http://www.writestarr.com
> President - Working Writers of Wisconsin http://www.workingwriters.org/
>
> On 9/26/2014 11:53 AM, Nancy Allison wrote:
>
>> The RTFM discussion concerns only calls that come in. It does not
>> concern, or quantify, the calls that did not come in because people
>> did
>> indeed consult the manual, got the answer they needed, and therefore
>> did not call.
>>
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Read about how Georgia System Operation Corporation improved teamwork,
> communication, and efficiency using Doc-To-Help | http://bit.ly/1lRPd2l
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> You are currently subscribed to TECHWR-L as hannah -dot- drake -at- formulatrix -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
>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Read about how Georgia System Operation Corporation improved teamwork, communication, and efficiency using Doc-To-Help | http://bit.ly/1lRPd2l
