Does Merging Support Content with Documentation Increase Findability?

by Tom Johnson on May 1, 2013
categories: technical-writing

In many companies, documentation and support are different kingdoms, with their own tools, processes, and workflow. As such, the content usually remains separate. When users need information, they have to search different content repositories (that is, if support even even makes its content accessible to users at all).

It seems natural that combining the search scope to include both support content and documentation would create a winning scenario for users. So why is it that these two groups tend to remain so disconnected?

Pace Layering

Pace layering is the idea that change takes place at different rates for different groups within a company. A business person may change at a much faster pace than other groups, such as IT. The “clock speed” of the infrastructure team may be slower than the clock speed of the social media team. Support can make changes more quickly than documentation. And because these clock speeds move at different rates, one group gets frustrated at another for being so slow.

An army of support agents push out new knowledge base articles or forum replies each day, providing answers to specific questions. Support agents rarely update old knowledge base articles -- they're moving too fast with new knowledge base (KB) articles.

Support also only creates content on an as-needed basis: if someone has a problem, support creates documentation for it. Support doesn't anticipate a user's questions and needs with KB articles ahead of time. Almost all content is written post-release.

Support agents often measure the time it takes to close a ticket, and they carefully track and set goals for a more efficient ticket process.

In contrast, documentation works more slowly, producing a larger body of content and ensuring the content is coherent, interconnected, updated, uniform, in alignment with style guides, and so on.

At its fastest, documentation keeps pace with an agile release cycle, which may push out releases biweekly. As releases often slip, documentation's publish rate gets even slower. Basically documentation just has to keep the same pace as engineering.

Documentation is almost always working pre-release, anticipating questions and and needs rather than working from existing questions and needs. As such, documentation has no clear boundaries with scope. Depending on the anticipated questions, the documentation could be sizable (it has to serve everyone, not just the confused user who called support).

Merging Documentation and Support

One way to combine documentation with support is to push the content from both groups onto the same platform. For example, if your company uses a web-based CMS, you could publish support through a forum and documentation through articles. The platform's search would naturally group both.

Through faceted browsing with the results, users can choose the type of content they're looking for. For example, if users know they're looking for a specific issue or bug, they may peruse forum results. If users are looking to better understand a process or feature, they may peruse documentation.

If the two platforms are unavoidably disconnected, you could create a custom google search that includes results from both sites. Or you could talk with your search team about modifying the search scope. There are probably a dozen ways to accomplish it technically if one truly wanted to.

Integrating Answers from Support into Documentation

Unifying the search is just one strategy for combining the information. The next step is to actually integrate the information from support into documentation itself. Documentation should regularly review support tickets and incorporate the answers into documentation as needed. The workflow from support into documentation should be a defined and regular workflow.

However, few companies successfully implement a support to documentation workflow. I assume this is because documentation tends to separate and distance itself from support. Technical writers like to focus on key features in a focused way, rather than writing patch documentation in twenty different directions at once.

More practically, documentation often doesn't answer to support. They are separate groups with separate political and benchmark structures. Because the departments often operate separately, there's no compelling reason to combine their results. They are like two teams who occasionally see each other at the same ballpark but never play on the same team.

Other Political Issues

Othe reasons why documentation and support remain separate may be distrust of each other's content. Support content may be outdated, ugly, poorly written, and hard to understand. A technical writer who takes pride in clear, accurate content might balk at mixing with content.

For more on this topic, see this post on Docops: Interview with Jim Turcotte.