When was the last time you read a FAQ?
No, Seriously. When was the last time you 'actually' read a FAQ?
When was the last time you found a FAQ useful?
Thought So.
Kevin Kelly refers to Most FAQ’s on the web out there as “NAQ" or as he prefers to call them, "Never Asked Questions”:
| That's what most company FAQs really are. Easily answered questions that no one has ever asked. These fake FAQs are useless. They are a turnoff to potential customers looking for reasons to buy, and an insult to existing customers troubleshooting. I now judge companies while shopping on how competent their FAQs are. |
I've hardly ever found a FAQ section of any web-site useful. FAQs, over their long history have turned from something that was supposed to provide genuine help, to something that no-one reads and a rather elegant wall or facade behind which most support folks hide.
The idea of having FAQs wasn't always such a bad idea. The whole idea of documenting FAQs in-fact started with an intent that was good:
| FAQ's started as lists of answers to common questions in Usenet newsgroups. Mark Horton wrote the first FAQ, which he regularly posted to the Usenet newsgroups with the answers to eighteen common questions, such as "What does 'foo-bar' mean?", and "What does 'Unix' stand for?". |
History has it that FAQ’s were written primarily because the same questions were being asked too many times:
| On 15 September 1983, Jerry Schwarz announced on net.general that he was going to publish a list of "questions not to ask". On 1 November, he published the first Usenet FAQ under the title "Frequently Submitted Items". |
They were, as their name suggest, supposed to be 'Frequently Asked'. They were supposed to help; back in the old days; when we didn't have this thing that we all love and call 'Google', FAQ's as a matter of fact, did help.
Today, I have multiple gripes with FAQ's.
The biggest of my gripes is that they are not written with a genuine intent of helping end users. Go to any web-site that has a FAQ section glance through them. Chances are, that you'll find the following whole set of issues with the the made up questions and their plastic answers. You'll notice that the question and answers are:
- Written by Non Technical Staff who usually come from backgrounds like marketing or content writing.
- Written by folks who are usually overly aware and cautious of the organization's image in front of it's customers or potential customers.
- Written to spoon-feed the users with questions the organization wants them to ask, not the questions the customers want to ask the product developers.
What historically started as a means for the technical folks to avoid repetitive answers in the community and support DRY communication, has gradually turned into a wall preventing customers from reaching the technical staff in a desperate attempt to lower the cost of support; or a place where a bunch of desperate marketers try to convince the 'potential' customers that their product works.
With all due respect to the marketing and PR folks, FAQ is supposed to be a support tool, not a marketing tool. Neither is it supposed to be a wall behind which the support staff hides.
The folks at 37Signals have a slightly different take on the whole support thing:
| Avoid building walls between your customers and the development/design team. Don't outsource customer support to a call center or third party. Do it yourself. You, and your whole team, should know what your customers are saying. When your customers are annoyed, you need to know about it. You need to hear their complaints. You need to get annoyed too. At 37signals, all of our support emails are answered personally by the people who actually build the product. Why? First off, it provides better support for customers. They're getting a response straight from the brain of someone who built the app. Also, it keeps us in touch with the people who use our products and the problems they're encountering. When they're frustrated, we're frustrated. We can say, "I feel your pain" and actually mean it. |
Kevin explains in his post also why real providing answers to real FAQ’s which can solve real problems and genuinely help customers are very difficult to write:
| Real FAQs will often be difficult to answer. An answer may mean admitting mistakes, or acknowledge a weakness, or explaining something very complicated. It's okay. Take all the room and time you want. People will read it. |
Let's face it. If your Web-site has a FAQs section it's probably going to suck. It's that Simple.
Don't have a FAQ. Throw them out of the window. Delete that FAQ page from your web-site. Right now.
Instead:
- Have product blogs with comments turned on so that product team can directly answer and respond to the questions. Let the search engines index those and help customers who have similar problems in future.
- Have forums. Get your technical team to answer questions there. Undermining the power of the community and trying to replace it with a ‘one-way-communication’ like a static FAQ list is stupidity.
- Provide email addresses and support numbers clearly and liberally on your web-site. If your customers have a problem with your product, your product team needs to take the responsibility and answer them. After all supporting what you write and being their for your customers is as important as writing the product itself.
If the same questions keep popping up again and again (and if you must), then, by all means, use a FAQ. But remember what a FAQ is supposed to mean in the first place.
Does your web-site have a FAQ section?
Is it written by your technical team or your Vice President of marketing?
Maybe it's time to give your FAQs a good hard reality check.
If they are not genuinely helping your customers consider throwing those stupid (In)Frequently Asked Questions out of the window.
Comments are closed.