Lots and lots of people don't read FAQs. They don't even read instructions on how to download something or register software, they just write to support ("where is my product?"), so my advice is: FIX YOUR SOFTWARE.
Example:
BlogJet (blog client I wrote) required entering XML-RPC endpoint URL for a blog to create an account. Of course, few people knew the endpoint URL for their blogging engine, so 80% of support requests were customers asking for help on configuring their blog. FAQ didn't help (yes, I tried); the solution was to automatically detect XML-RPC endpoint URL from their blog's URL. After I did this, the percentage of such support requests dramatically dropped.
The next 80% was customers asking to resend their registration keys. I just wrote a system to automatically resend them, so people no longer wrote to me, they just filled a form and received a key.
The next 80%... The point is, find those 80% identical support requests, fix your software or add automation to eliminate them, then repeat. Most questions that can be answered by FAQ are things you can fix in software.
As for the system where customers enter their question and get redirected to the related question in the FAQ (see Wordpress.com, Google) -- people hate this, just like they hate browsing phone support systems looking for a way to contact a real person.
This is in line with the philosophy espoused in Donald Norman's book, "The Design of Everyday Things". Mr. Norman phrases it as, "a product ought to afford being used correctly", that is, one cannot help but use it without being confused or reaching a stopping point, simply due to the nature of its design. His prototypical counter-example is the lovingly-named "Norman door", which is any "PUSH" door having a handle, or any "PULL" door having a push-plate. "PUSH" and "PULL" signs are essentially FAQs that make up for the "poor design" of a door that does not afford being used correctly.
We totally agree. That's why we automatically pull up related FAQs but don't pull the customer away from their flow of writing a message to you. We've found it works quite well, as demonstrated by the numbers. It's not annoying like the latter system you mentioned, but surfaces those FAQs that could have helped with that 80%.
I just watched your demo video, and the system looks nice and very useful, unlike those I wrote about in the last paragraph -- customers instantly see the answer to their question without interruption.
When I worked on Qt I would monitor various mailinglists and when I would see more than one person asking how to do X I would often go and figure out why the documentation didn't provide that answer.
One simple example is that when using QCryptographicHash a common operation is to compare the results to a hex string. QCryptographicHash::result() returned a QByteArray which isn't a hex string. So after seeing more than one person ask how to do this I added a "\seealso QByteArray::toHex()" to the documentation.
Another favorite thing to do was if people were looking for a function say called "Foo::search", but it was actually called "Foo::query" I would add the word "search" inside of the Foo::query docs so at the bare minimum if they searched on the Foo page they would find the word search and the api they needed. Often after that help for Foo::search disappear. (or to do bla you have to call X() and Y(), mentioning bla in X and Y's docs really help)
There was a lot of pride in the Qt documentation and little improvements like this all of the time really helped to make the dev experience better.
Papering over user support with an FAQ is addressing the symptom, not the problem. You should consider an FAQ to be a stop gap, until you fix your bad software. Example:
We get a request or two per week in Gaia GPS for people asking "How to I delete a waypoint?" and other people seem to search for "Gaia GPS delete waypoint" on Google too. To do this, you swipe the row of the waypoint to be deleted in a table view, and a delete button appears. This is how the native iPhone email works.
We describe how to do this in a page in our help describing hard-to-find-features (the top page in our Help manual even). But really, we need to make it more obvious to everyone how to do it.
To solve this problem, we changed the software this release to add a delete option to the details page of each object. When this is approved, I imagine all the support will disappear.
Agreed that you should be making your product better...I think that's perhaps the unsung goal with our reporting system. If an article gets read a lot, look at how you can improve it in your product.
But you can't fix things fast enough and there will always be someone confused (If you build it one day, user X will be confused. Build it another, user Y will be confused.) so having good documentation is key, in our opinion.
You just have to be sure you don't eliminate the customer support with documentation, and then not ever fix the problem. I think it's better to feel the pain in the short run, and have a better product in the long run.
This reminds me of another thing we do - when we make new apps, we don't provide a manual to the beta group. We make one after the fact, but we want to get feedback from users as if there are no instructions.
Your product is awesome btw. We use it in two apps, and plan to add it to a third soon.
Totally! I'm obsessed with telling our team about customer problems, our support folks are obsessed with helping them, and our Head of UX is obsessed with fixing the actual problems. It's a good set of checks and balances.
Thanks for the kind words and for being a customer! :)
I also disagree with this assertion - "If you build it one day, user X will be confused. Build it another, user Y will be confused."
I agree that you can never make a product that 100% of people can use with ease, but you can get close, and you can make changes that help User X without alienating User Y.
Case in point: iPads don't come with instruction manuals, and toddlers and old people both use them with ease.
"You give the same answer you always give. Another 5 minutes of your (and your customer’s) life wasted."
For certain types of businesses having the customer send you an email that you have to respond to (and we use auto complete emails so they are knocked out in < 30 seconds) is a great opportunity to try to sell them something else or even answer a survey question etc.
After all companies do all sorts of things to get customer interaction. There is nothing better than building customer loyalty (once again depending on the particular situation) by using this as a way to send a seemingly personal response which someone will definitely be reading and not ignoring like a sales email. Even if you are not selling anything there is a value to that.
What's wrong with showing an extra line saying, for example, "by the way did you know that we also offer site monitoring which you can get for an additional $ per month"?
It's similar to the viral marketing that started with the "get your own free email at hotmail.com" as a result of Tim Draper's suggestion...
I want you to fix my problem. If something is broken enough that I need to contact you then, in my mind, your only priority is to get me working again.
Associating your other products with the faults I've found in the product I'm using might be a sub-optimal marketing strategy.
Shoddy math. You can't take the average time to answer a customer inquiry and then assume that reducing the number of inquiries will reduce your work load by that much. The questions that can be answered by a good FAQ are precisely those questions that can be handled quickly.
In other words, it overestimates the time savings from having an FAQ.
You have a point about the actual amount of time saved, but there are plenty of questions that are very complex that can be answered by a good FAQ.
For example: we offer Single Sign-On for UserVoice. If we didn't have any documentation at all about it, we'd spend many, many more hours answering basic questions like "how do I set up SSO?", "how can I encrypt my JSON token?", etc. Yes, we still have to answer specific questions that can't be anticipated by an FAQ, but we've saved ourselves many hours with this documentation.
I write the FAQs for the company I work for and believe me, they do. Not all of them of course, but I've seen enough visitor stats, search queries (with and without results) and emails to know that some of your clients will go out of their way to look for the answer online before emailing.
Customers will give up if a) the FAQs or help system isn't easily reachable, or b) if the FAQs and help system sucks.
The best thing you can do if "people don't read the FAQs" isn't to trash them - it's to make them better.
That's not what our numbers are telling us. Yes, some folks will never read. But there are plenty of folks who just don't want to go digging through a big ol' FAQ. That's why pulling up matching articles while they type has been so effective for us.
I worked email support for a website once upon a time. I'm pretty sure 40% of the emails were "I forgot my password", despite a large "Forgot Your Password?" link on the top of every page next to the login box. And this was a rather technically-oriented website, too; most of these people had to be fairly tech-savvy to even be using the site in the first place. If those people can't read the site enough to find a link in the obvious place, my hopes of getting anybody to read a FAQ are not very high.
The problem is that people aren't perceiving the link to be applicable to their situation for whatever reason. A better solution rather than investing more time in handling emails would be to alter the message the user sees when they get the login wrong:
"Invalid username and/or password. Would you like us to reset your password for you? [button: YES, reset my password]"
If the user simply mistyped their password they can ignore the prompt and try again. If they click the YES button, direct them to a page that has the email address they entered pre-populated and a "Reset My Password" button with clear instructions elsewhere on what to do. For example, an arrow to the email field with instructions on ensuring the email address is correct; another arrow to the button with instructions to click there. Clicking on the button then shows "We have sent an email to <your email address>. Please follow the instructions contained in the email to reset your password." The email would contain a link with a time-expiring token that, when clicked, lets them specify their new password.
With that approach you could have reduced those types of emails to mostly situations where the user did not get the email.
Your giving me Kodak software flashbacks. The software was god awful. Right from login. New password required every few weeks. Can't be related to your previous one, and the 'change password' button that you had to click took you to a page were you had to type username, then new password 2x, then old password (in that strange order). However all the boxes were unlabeled so you had to guess were what went. I emailed Kodak every time just to make a point. It makes me so angry every time I see a Kodak logo now.
It is a lot more than a FAQ: it has a somewhat good search feature, and also directs users to an intro tour, the forums, and votebox (a place to request and discuss features).
Improving it is a bit more complicated than just getting analytics around how many hits on /help end up searching, reading help articles, and maybe filing tickets. There is a lot more needed to understand which areas of the help center aren't getting enough prominence, which topics are just missing, and also how we could create some automated tools to help people find sources of problems. For example, if you are over quota, we should tell you that prominently on /help. Getting automated feedback on search results (clicks on help articles increasing their rank for a given query), and also from ticket responses (the article which would have answered the question needs higher rank for the original query) is a huge area of potential improvement, but both require a fair amount of work.
The potential impact is actually huge: would we need to double the size of the support team if we double the userbase (yet again)? If you're interested in hearing more about this, and especially if you've like to help build these systems, shoot me an email: [email protected]
This would be fantastic in an environment where you have a consumer base - but we're still trying to solve the problem where we have a huge amount of technical information for our professional customers and it's difficult to find - even for our support staff as some issues only come up rarely and we forget where we put the solution.
We're actively looking for this solution if anyone has something that would fit this need.
Example:
BlogJet (blog client I wrote) required entering XML-RPC endpoint URL for a blog to create an account. Of course, few people knew the endpoint URL for their blogging engine, so 80% of support requests were customers asking for help on configuring their blog. FAQ didn't help (yes, I tried); the solution was to automatically detect XML-RPC endpoint URL from their blog's URL. After I did this, the percentage of such support requests dramatically dropped.
The next 80% was customers asking to resend their registration keys. I just wrote a system to automatically resend them, so people no longer wrote to me, they just filled a form and received a key.
The next 80%... The point is, find those 80% identical support requests, fix your software or add automation to eliminate them, then repeat. Most questions that can be answered by FAQ are things you can fix in software.
As for the system where customers enter their question and get redirected to the related question in the FAQ (see Wordpress.com, Google) -- people hate this, just like they hate browsing phone support systems looking for a way to contact a real person.