Pitting tech comm and tech support against each other
Technical communication and technical support should be allies. After all, tech support needs the information that tech comm produces. Tech comm often has only limited customer contact; tech support has oodles of daily customer contact.
And yet, there is a common organizational pattern where tech comm and tech support are in conflict.
I’ve seen this problem in a number of organizations with a few variations, so what I’m going to describe here is a composite picture. It does not represent any specific company.
The technical communication group creates official documentation. It is written, edited, reviewed, approved, produced in a nice format, and made available through official channels.
The technical support group is expected to use the official documentation. However, there are a few significant problems for the tech support group:
- Tech support staff is unable to find the information they need quickly. When on the phone with a customer, tech support does not want to search a pile of PDFs, then wait for a monster PDF to open, then search the PDF again to find the appropriate spot.
- Because of review, approval, and production cycles, it takes time for the newest information to make its way into the official documentation. But tech support needs the newest information because it’s inevitably why people call.
- The fixes provided by tech support are sometimes quick and dirty solutions rather than the approved, official, safe way of doing things.
Why do these problems occur? Consider the tech comm group’s situation:
- Why PDF? Because of regulation, tradition, or established workflows. And often, because generating PDF is the path of least resistance.
- Why isn’t the newest information available? Because the company requires reviews for legal, regulatory, or risk management issues.
- Why are the tech support solutions not in the documentation? Because these solutions do not work properly in all circumstances.
Tech support is one of tech comm’s most important customers, but is not recognized as such.
So. Tech support needs content. Tech comm provides the content, but not conveniently enough or fast enough. The result? Tech support begins writing their own content. This content is typically:
- Developed in a collaborative environment, such as a wiki
- Subject to minimal (or no) review
- Immediately available
- Searchable
The subject-matter coverage is uneven, as tech support will focus on areas where a lot of questions come up. The “obvious” content will get little or no coverage. The writing quality will cover the spectrum from fairly well written to basically incomprehensible.
The message from tech support to tech comm is, “You can take your beautifully formatted PDF and go home. What we need is speed and search, and you don’t provide either one.”
The message from tech comm to tech support, “The information you need is in our content. Please stop playing amateur tech writer and use our reviewed, vetted, grammatically correct information. We are getting it to you as fast as we can given the constraints imposed on us.”
Not a very satisfying situation for any of the parties involved. The solution, as you might expect, is that the parties need to meet in the middle. The tech comm group needs to:
- Provide information that can be accessed quickly; that is, HTML with search functionality and not monster PDFs.
- Shorten the release cycle for content so that information is made available more quickly.
- Pay attention to the issues raised by tech support to ensure that they receive good coverage in the documentation.
- Find a way to open up collaboration with tech support staff.
The tech support group needs to:
- Search the doc site as a first step rather than a last resort
- Avoid rewriting existing content
- Curate information to improve initial drafts
- Provide feedback to tech comm, such as a list of top issues
There are a number of possible unpleasant outcomes. I can’t quite figure out which one is The Worst:
- Tech comm and tech support do not collaborate. Over time, the tech support content “wins,” despite the limitations in topic coverage, formatting, and editorial standards. Tech comm drifts into irrelevance.
- Tech support content is shut down to avoid problems with “unofficial” content. Tech support uses paper notes and the office rumor mill to communicate tips and tricks.
- Both groups continue to produce content with significant overlap. Nobody does anything about the duplication of effort. The two sides occasionally contradict each other.
My recommendations for these situations are straightforward:
- Fix the PDF-only problem (this always seems to happen in PDF-only organizations).
- Provide excellent search capability for the tech comm content.
- Shorten the release/update cycle. Consider providing draft content for in-house use (with unreviewed new information flagged).
- Provide a feedback mechanism and use it. For example, provide information in a wiki for widespread collaboration or provide the the ability to comment on topics.
- Use tech support call logs to identify and address content priorities.
Tech support and tech comm can help each other. Tech support is both an information consumer and a subject-matter expert. Tech comm needs to recognize this special role.
Finally, a word of warning: An interdepartmental content creation death match is not the way to go.
About the author
rick
Interesting… I’ve always considered Tech Support to be one of my most important customers.
Bill Swallow
“Tech support is one of tech comm’s most important customers, but is not recognized as such.”
I’d argue that the opposite is also true. Tech support has so much insight to share that writers, developers, engineers, testers and other involved parties simply don’t have the direct bandwidth to consider. And rightfully so – it’s why you have multiple departments within established organizations.
The cold hard fact is that no one group can account for everything, so collaboration is key. Tech Support is not only the Documentation Department’s customer, they are their partner, as with all customer- and product-facing groups. If you’re not openly collaborating with all involved groups, you’re not getting the right work done.
Mike Starr
Tech support groups are not only some of our most important customers but they’re also some of our best subject matter experts and, if possible, should be some of our reviewers as well.
Jason Nichols
Thank you Sarah for this article. And I agree with your points. We are facing the same issues at my work, where Support last year launched it’s own Knowledge Base. But luckily the Tech Comm and Support teams have a good relationship, but we need to work closer. You’re right – a middle ground has to be found. The content Support create does not have to have passed a language review, and anyway Tech Comm would be hard pressed to find much time to review all this new and good content. It has to be said again – Tech Comm does not have a monopoly on content creation. And how can they? How can a small group of people know everything? Rather, we have to find ways to facilitate the creation and publishing of content by others, and the cooperation with Support is an important part in this.
Aaron Fulkerson
Awesome! Thanks for the article. You’ve nailed exactly what we’re seeing from our buyers at MindTouch. Our MindTouch TCS product, a social knowledge base, is being used across techcomm, custserv, SMEs and in many cases even with end users. We’ve strike a balance that seems to work for all interested parties and some keys, which you’ve highlighted are:
* wiki-like collaborative authoring
* workflows and/or content moderation queues
* curation analytics
I recently presented at WorldWare about this, which is what I perceive to be “product help communities”. This is the nexus of techcomm, customer support, marketing, and the end user. Here’s my presentation from that conference: http://slidesha.re/ezcmp8 I would appreciate feedback.
Also, I wrote about this for Forbes a while back. You can find that here: http://bit.ly/forbesdoc
Thanks for the great read.
Mark Fidelman
Could not have put it better myself. Bravo!
Paul K. Sholar
For most organizations, certainly for those not using an in-house wiki:
Implement a “documentation bug” option in the company’s bug reporting system. In that system, include meaningful fields that describe predictable kinds of documentation issues. Track when/where issues are resolved and when a correction is next to be published.
Marya DeVoto
I can’t imagine trying to write tech docs without the context of “How do we reduce Support calls?” It’s one of the key drivers for having official docs at all at this point. So yes, talking to Support would be a gimme even if it weren’t staffed by entertainingly odd people with amusing customer stories to share.
It’s also helpful to collaborate on decisions about which information customers can probably use unassisted and which information might enable an unskilled customer to bork the whole system. And to find out anecdotally how successfully customers are finding the info you have so lovingly organized and indexed.
Kristi
This is one of the reasons why I want to learn more about producing searchable web pages from our online help tool. We can get HATs, but getting a CMS (or a CMS that talks to support’s content) is trickier, in the places where I’ve worked, so far.
I did stumble upon something that brought support and tech comm a bit closer together at my last job: we surveyed users about user assistance and included some questions about the knowledge base, which was governed by the support team. Then we offered up the results (for example, comments that blasted the KB search) as ammo for a purchase request for new KB software.
I left soon after, but a possible next step could have been to start addressing some of the negative feedback by providing more seamless search of help and KB articles.
Sarah O'Keefe
@Paul: Bug tracking is definitely a good idea. I think in many cases, the conflict between these two organizations arises precisely because of a lack of clarity over when document updates might take place.