The problem with a lot of online and support options is knowledge base suffers from proximity bias. In addition to this, no one in the company tests their information architecture from a third party perspective. Since they know the exact terms, and have access to more detailed information,they never have to eat their own dog food.
While internal documents that tech support uses have step by step flowcharts of trouble shooting with a lot of detail and details exacting language, end users using the web site do not have access to the terminology. So often they must try searching multiple variations of terms to find the “magic words” to describe the problem to find the KB article that gives an answer.
The same is true for the actual articles a user finally does find. A lot of guides for software written from the perspective of someone that already understands the product or process and often the information needed to solve a problem is broken up into multiple pages that make it easy for a person to lose their way on the trail to find solutions to their problems. I plead to companies letting the developers write the final end user docs to stop this, and hire an exacting technical writer that gets the new user perspective and the seasoned pro’s perspective so they can write documents that help both of them.
Instead of writing half answer that most pages provide, take the dev and support docs, hand them off to a technical writer for “translation” so they can add other phrases to the metadata that end users might use, and rewrite then targeting either those new to the product but very technically proficient (often my category) or new to the entire product concept/category.
For new users, “How to do X” Guides should be able to walk through both new and experienced users with accurate, clear, and complete steps for those that know what they want to do. (Note: I won’t get into breaking from the limiting physical page concept to improve the presentation design here to enable docs to cater to both audineces, because I have touched on this before, and have more to say.) While more detailed “Why?” Technical notes could provide an overview to give people an understanding of why this or that is the way it is, and why it needs to be done. This will help advanced users solve their own problems and give new users a path to mastery. A basic way to make it happen is with annotated examples and various scenarios (tasks a user might want to accomplish, or sets to solve a problem) would be a plus. Obvious paths leading to either guides, tutorials and/or reference documents should allow users of different levels of expertise to “chose their own adventure” at the end if simple using dynamic text block folding is not an option. (Again this relates to breaking the limiting concept of a physical page.)
Bad user documentation that is either poorly written, of limited use (“contact you administrator for your settings”), or has no logical next page, is what has often stopped me from buying and recommending a lot of things that were otherwise decent products and or software. Why? Most of the people would not know what the mysterious next step is after “contact your network administrator.” After this either they would give up in frustration, call me, or get someone that “understands computers” gouge them for a 5 minute fix.
Sorry, but I would rather have good documents to quickly solve my own problem within 5 minutes and never need to call support and spend 15 waiting for supposedly good support — where, quite often, the person answering is less technically proficient than I am and reading from a flowcharted script.
I might be an “edge case,” but when a company needs to improve a product, it is my belief that pushing the edges is a way to improve any system, app or process. I do not consider myself “elite,” but I do know that my 3+ decades of computer experience and knowledge that came with self-troubleshooting and providing support for others either professionally or casually often places me in a category far above level 1 support abilities. I try to let them know: “If I’m calling you, this is probably a case for someone that truly understands how the product works, and doesn’t need the troubleshooting flowchart to guide them.” Why? I have already looked the online documentation, and either the information I need is not in there and/or the knowledge base design is horrible — which is extremely common. Experienced user often look for the answer first before calling support. If they cannot find it, but the documentation exists it is a symptom of either poorly written documentation or bad documentation organization and search on your support site.
Documentation is a type of support that has a one time cost and minimal update costs if done well, vs. answering the same question from different users over and over. If your docs are changing rapidly or change significantly between releases, then this is a symptom of a product design that is in flux due to either a fundamental misunderstanding of good design, or no clear idea of what the product should do or how it should function.
BTW, train your support staff to not only read the support request, but understand if it is addressed by prior documentation, because there is nothing more insulting than seeing a link to a document you know doesn’t help despite taking the time to write explaining that the document does not apply in this case or that you already read the page that they just linked to you again, and again. (I am convinced Skype does not actually have human support staff because of this type of form letter response to any support request.)
Long ago, all users had was documentation in the form of a printed manual. The problem was, many people never read them and turned to the 1-800 number. As the population of end users grew, the percentage of people that never cracked the manual went up, and support costs with them. Most companies, in an effort to trim costs, stopped including printed manuals in their shrink-wrapped products almost 2 decades ago, however, it took another decade before most companies provided anything close to the scope that the printed manual provided online.
To this day, it is easier to use a search engine to find answers about commercial products than it is to find them on the company’s product site. The companies often do not have the resources nor professionals with metadata and thesauri skills in-house to match a search specialist. They also see no incentive to improve them since they cannot quantify the cost of improving them against a drop in support call volume.
While logically, it is easy to see how having support resources online to pre-empt needs to call tech support would save money in staffing, most businesses only categorize things in 2 columns: expenses and revenue, and do not differentiate expenses that lower other costs vs. other operational costs. To most executives, tech support is a cost center, and not valuable infrastructure that can be leveraged to make things run smoothly. Unfortunately, since you can’t quantify things that were never needed, few people see the need for support especially if everything seems to be running smoothly.