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
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.