Your FAQ could be answering 40% of support requests and save you 8 hrs/mo
1–10 of 35 posts
Re: Your FAQ could be answering 40% of support requests and save you 8 hrs/mo
#2So why the hell are we still wasting time responding to the same damn questions?
Because customers never read anyway.
Re: Your FAQ could be answering 40% of support requests and save you 8 hrs/mo
#3So why the hell are we still wasting time responding to the same damn questions? Because customers never read anyway.
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.
Re: Your FAQ could be answering 40% of support requests and save you 8 hrs/mo
#4Lots 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.
Re: Your FAQ could be answering 40% of support requests and save you 8 hrs/mo
#5That is an example of a great headline. It's amazing how effective good copy writing is.
Re: Your FAQ could be answering 40% of support requests and save you 8 hrs/mo
#6I 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.
Re: Your FAQ could be answering 40% of support requests and save you 8 hrs/mo
#7Lots 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 reque…
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%.
-Evan Hamilton Community Manager, UserVoice
Re: Your FAQ could be answering 40% of support requests and save you 8 hrs/mo
#8So why the hell are we still wasting time responding to the same damn questions? Because customers never read anyway.
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.
-Evan Hamilton Community Manager, UserVoice
Re: Your FAQ could be answering 40% of support requests and save you 8 hrs/mo
#9Lots 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 reque…
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%. -Evan Hamilton Community Manager, UserVoice
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.
Re: Your FAQ could be answering 40% of support requests and save you 8 hrs/mo
#10Lots 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 reque…
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.