Case
Ever since we’ve released an update for one of our products, about six months back, we’re registering (and addressing) a lot of data-integration issues for our customers. Most of our small-scale clients, who encountered integration issues, use the same version of packaged accounting ERP system, which has an incorrectly designed integration logic. Consequently, the integration terminates before updating records.
Questions
As a technical communicator, is there anything that I can do to help my customers? Can I design my documentation to communicate the underlying issues before my customers encounter them? Can my current documentation bouquet, which does not include FAQs, provide solutions? Can I provide the solution before such issues arise? In this post, I’ll discuss if the frequently asked questions document can be the solutions for the questions.
Observation
In my current stint, we do not have a fixed set of documentation for our products; everything depends on the needs of our customers. For example, the troubleshooting guide and What’s This? (context-specific help) document are not available for all the products. Additionally, we do not prepare FAQs (as I mentioned earlier) for possibly the following reasons:
- FAQs contain only generic, assumed questions that customers “might” ask.
- FAQs do not include header-level information, but line-level information.
- FAQs, generally, do not apply to most customers – Customer X uses some features that do not apply to the needs of customer Y.
- It is assumed that FAQs should contain crisp, quick information; given that (in our company) we have detailed procedures to configure and run our SAP-based forms, it is a daunting task.
- Mostly, FAQs are redundant, because they include repetitive information, which can be found in a detailed manner in other types of documents.
Solution
A lengthy discussion regarding the increased number of data-integration issues, which followed the other day, concluded that we focus (and rush on) two things: first, resolve the issue; second, provide required information in documentation so that customers either do not encounter such an issue or know how to deal with it. With this purpose, I sat with the subject matter experts (SMEs) to gather whatever I could, and design the outline for the document. What turned out in the end was a redesigned form of FAQs, which I’ve named as FAQs 2.0.
You may look at the picture for reference. Pardon my graphics, but they sufficiently explain the idea. The tasks of similar nature or business needs are clubbed under one heading, and hence circled in the picture below. Once all the tasks are grouped (or prepared), they are categorized under topics that help form the FAQs.
Another important step is to not stop at clubbing similar or related topics. So, based on my interaction with the SMEs, I gleaned that our customers did not receive any communication from their packaged accounting ERP provider about the integration issues. This meant additional work for me, because I had to jot down the troubleshooting check points into the initial draft, and incorporate the most critical ones from that list into the final document. My conclusion: It at times helps to include the third-party information as well; provided it has business value for your customers and helps improve their understanding.
Now, the issues that our customers encounter when integrating their data have greatly reduced. Also, when the customers encounter issues that are not covered in the FAQs, my support team details me to incorporate the scenario into the document.
Analysis
I see that I am not the only one who’s following the logic. A week back, I purchased a new phone – Nokia Lumia 1320. Nokia has placed the configuration and quick reference information under the How To section on its Windows Phone website. The navigation through the configuration settings is easy to follow and implement. And, of course, the phone’s functions too are intuitive, so I hardly needed to go to the website.
Let us take an example to understand the flow of logic in reference to the following graphical representation. Before I switched cellphones, I was facing a lot of problem in managing multiple accounts in my cellphone. Previously, I was using a phone that did not allow me to link multiple accounts or entries within my cell phone. In comparison to that phone, my new Nokia Lumia 1320 is capable of linking not just the accounts of my friends on social network with their corresponding entry in the phone, but also their multiple or duplicate contact entries within my phone with each other.
With respect to the above picture, the trouble of “missing links” is the problem statement (or Benefit – when resolved). The value proposition lies in cross-linking multiple or duplicate entries on the contacts lists with the corresponding social network accounts. Note that the Feature in this case is not the value proposition discussed above, but that the phone automatically does all the linking in most cases. The process that I follow to link accounts will become my list of tasks. Gradually, I can group similar lists to form a topic. Bottom up, therefore, a topic contains its own list of tasks and their corresponding features (and hence benefits). So, in this case, tasks like Creating and Editing Contacts or Finding or Filtering the Contacts will group to form a topic. And, in the end, all of such topics put together, become your FAQs.
Another outcome of such an exercise is that by the time your customer reaches to the last link, they’ve learned a new thing (without knowing about it) – Such passive learnings contribute to brand loyalty; but we will talk about it some other day.
Conclusion
The point here is: the FAQs, as I see, are designed not on the constraints of what the product delivers, but how it is useful for my customers. When I compare the FAQs I created with the How To section on the Windows Phone website, see that the following outcomes are common:
- The new FAQs contain exactly what my customers need.
- The new FAQs are categorized, yet detailed.
- They contain the information that cannot be included in any other kind of document – it’s a combination of troubleshooting comments, FAQs, and configuration settings.
- I have a value proposition that inversely relates to the support costs. In most cases, the better I document, the lesser the support calls cost.
As of now, we have been successful to create business-driven FAQs document, which contains troubleshooting information, along with other customer-centric, line-level questions (categorized by header-level groups that are linked together as topics). So, I am still in the process of evaluating the effectiveness of this approach, while (partly) reaping the benefits it. Let me know your comments.
The Wordsmith 