Why Do You Still Have FAQs for Your Website?


A Frequently Asked Question section (FAQs) is without a doubt the most commonly used tool in self-service. Whether it’s just a few questions on a “Contact Us” page or Zappo’s massive, eternal scroll-fest, FAQs offer a simple way for customers to scan for topics and solutions.

But now for some things you may not know:

Have you ever thought that your FAQs may be hurting your self-service? Every time I have used FAQs, they have indeed, helped customers get to a solution faster. However, FAQs can distract customers from answers that require a search or that may be at the bottom of the list.

For example, customers looking for a how-to solution may see a technical issue that is curious to them and click on it – aaaand there they go – one step closer to a live agent touch.

Customers tend to feel that their question is the most important question. They are right! However, an FAQ list should be limited in its length, and forcing customers to read 10-15 lines of questions or titles is pretty horrible.

Think of it this way: let’s say your FAQ titles are using some basic best practices. Your title keywords and the length of the titles are at a trim 65 characters or less (SEO standard stuff). That would be a maximum of 650 characters, 127 words, for 10 FAQs and 191 words for 15 FAQs.

Don’t make FAQs questions like poetry in commotion

Since many FAQs are formatted as questions, (“How do I ______” or “My  ____ is _____. How can I ________”), not only are the questions most likely going to be 65 characters or greater, customers generally have to read through a lot of superfluous text just to have their question validated. That block of FAQs can then go up to the size of a pretty hefty paragraph that may more closely resemble a Shakespearean sonnet.

Now, check over this list to find the line that means the same as “proof of eternal happiness”.  And make a note of how long it takes you to find it.

READ  How to Make Human-Friendly Customer Service Automation

faq questions for website

  1. Who, if it were in plenty, still would want
  2. Before it may enjoy his better part:
  3. From which detained, and banished in th’ exile
  4. Of dim misfortune, has none other prop
  5. Whereon to lean and rest itself the while
  6. But the weak comfort of the hapless, “hope.”
  7. And hope must in despite of fearful change
  8. Play in the strongest closet of my breast,
  9. Although perhaps I ignorantly range
  10. And court opinion in my deep’st unrest.
  11. But whether doth the stream of my mischance
  12. Drive me beyond myself, fast friend, soon lost,
  13. Long may thy worthiness thy name advance
  14. Amongst the virtuous and deserving most,
  15. Who herein hast forever happy proved:
  16. In life thou lived’st, in death thou died’st beloved.

Did you find it? It’s number 15.

That’s exactly what it’s like coming to a support site with an *idea* of a question and being greeted with a list of FAQs. It seems logical to anybody making a support website to have an FAQ list. It’s what everybody does. It’s considered a best practice.

But when I was leading the strategy of a recent project, one of the design mockups came back with FAQs on the front page of the support site. I requested that the FAQs be removed, which led to an interesting discussion where they were removed for the release and inspired this post.

So I am not saying that FAQs should be non grata in your Support Center, but do make sure to follow your metrics of your touch rates and article views after modifying or adding an FAQ.

Final 5 on FAQs for websites

Here’s a handy list observations and rules I generally follow regarding FAQS:

  1. FAQs will devalue your knowledge search box. In another site I worked on, we reviewed the click map of the support center. Where pages with both a search box and FAQs, we saw a significant drop in search box searches usage. When there was a more prominent search box and fewer FAQs, people tended to search for their question before clicking the FAQs. (This scenario also affected virtual agents, devaluing their ROI).
  2. FAQs will give you false positives. If you’re using your knowledge platform to host your solution-based FAQs (many don’t), then you risk inviting customers to click on topics they didn’t come for, but become curious about when they see it. All of a sudden, what you thought was filler becomes a puzzling trend you have to explain for your weekly analytics report.
  3. FAQs have to be routinely maintained. Support content creators are at the mercy of the dev team to update support pages – and many find that requests fall to the bottom of their priority list. This makes updating FAQs a clunky, time-consuming task. Staff dependencies, outdated information, and critical issues are all setbacks to a current and relevant FAQ system. If it were up to me, FAQs would be adjusted almost daily.
  4. “But what about dynamic FAQs?” The coding involved to make an intelligent, dynamic system is nearly impossible. “We’ll have it display the most popular and most recent articles.” Great, but see point 2. Not every new article needs FAQ visibility.
  5. And the biggest point… Your search box is your most powerful asset. Customers arrive at your support center with a question in their mind. People don’t want to read what they are thinking. In the early days of the Internet, there was Yahoo!, then a directory service were you browsed for your answers. Then Google came along and let you simply ask a question. Which one do you use?
READ  6 Ways Marketing and Support Can Work Together to Improve Customer Experience

The bottom line on website FAQs

Use your support page as a place for answers and education. But don’t send them on an Easter egg hunt. There is a place for FAQs, but they should be kept to a minimum, and should be a mix of post-sales and technical questions.

faq example for website by Kayako

What to put beneath your huge search box?

Focus on support links (community, downloads, mobile stores). Categorize topics where you can direct customers to those category pages for a longer list of specific and top FAQs (15 max). Your customers’ heads are popping with questions and looking to have their choice in you brand validated with great service. Why make them read more than they need or want to? Let them ask.

Your Free Help Center Health Check Template

Don't miss our latest success secrets

Want the best customer support and startup content delivered straight to your inbox?

About the author
Jon Meyer

Jon Meyer is a contributing writer at Kayako. He is a self-service expert with over 10 years of experience. Jon is passionate about the exciting intersection of support and design while helping companies reduce customer effort with beautiful, intuitive support experiences.

  • Mad Bernard

    I feel like you mean well, but your perspective on this has lead you to a horrible conclusion. I hope its fair to boil your argument down as, “FAQs distract people from the search box and provide lots of information they didn’t ask for”?

    However, look at your point that it’s hard to explain clicks on random FAQ articles at a meeting. You suggest destroying a thing about your site that your users are actually engaging with, in order to have an easier time doing internal stuff that is probably a waste of your time anyway? Your perspective seems to be that of a designer who wants to frame the most beautiful screenshot, not someone focused on users.

    Your suggestion that search boxes are better than FAQs is a message from a world far different from the one I’ve lived in, where search boxes 30% of the time don’t work at all, 30% of the time turn up a random assortment of dozens of robot-focused pages that have some irrelevant combination of the search terms, and 30% of the time turn up a few results that spoonfeed the basic concept without solving the actual problem.

    A FAQ tells the user the shape of the user experience of the site. “I had a seizure” = ok, I shouldn’t recommend this site to my sensitive friends. “How do I make this awesome thing happen” = whoa, this site can do the awesome thing?!

    Just in the past 24 hours I used Smugmug’s frustrating search, got nothing, and then composed an email to ask them my question; whereas on Product Hunt I scanned over their FAQ, answered my question, and learned interesting new things about their site.

    Making it harder to learn the basics of a website is just wrong-headed.

    • Jon Meyer

      Hey Bernard

      Sorry for the delay getting back. I swear I haven’t been writing this response for 15 days 😉

      Thanks for the feedback. It gives me an excuse to address some caveats that there isn’t always time (or space) to address in blog posts. I’m excited to discuss, so this might get detailed 🙂

      “Views” data can be murky as they can come from SEO, FAQs, the open Internet, agents, etc. The best way to get intel on this is Google Analytics for referring pages. But even then, the SEO on articles maybe unoptimized properly leading to false positives. This means that the *relevance* of your clicks can be skewed by SEO, but by placing FAQs on a front page for curious clickers. Even heat mapping analytics of clicks on content, isn’t always a good indicator if intent – especially if an FAQ may seem extremely important, but only truly applies to a small subset of customers. So bringing that data to your team saying “Since we put that important FAQ on the front page, it’s received thousands of clicks. This issue is bigger than we thought,” can be a bad correlation, and an incorrect insight that could can unnecessarily escalate company resources.

      As for your experiences, FAQs and knowledge bases aren’t always the technologies fault, but the those who curate it. For Smug Mug, I agree that their search is frustrating. This is because the have used first person questions for their knowledge, a practice that take a lot of time to correct, but all too common for start ups who are scaling to medium to large companies. However, I did notice they seem to curate their synonyms well. For example, typing in “not bright” and “too dark” both bring up the article “My Prints are Too Dark!” (face palm on the exclamation point). However, in SmugMug’s case, I would recommend putting a top five FAQs over their “Help Topics” action and then reducing “Help Topics” from thirteen to ten…and get rid of the numbering.

      And then there’s Product Hunt. It’s a non-technical, straight forward site without the depth of information SmugMug has. However, where is the FAQ about writing personal messages to other users? How long would it take you to find it if showing up for the first time? How about a fresh example: Go to Zappos FAQ and find out about why your order may be delivered late. If you’re thinking of using the ’search within page’ function of your browser, then you have already preferred a search box.

      In short: “Scanning” – and even searching – an FAQ is completely based on the customer’s depth of knowledge of the topic and how well the company’s content team has written the titles. Where search boxes win is that they also search the body of the article for terms, errors, and features that can’t be scanned in a long list of FAQs (Product Hunt called them “private” messages in the title, but “direct” messages in the body – and old search engine trick). Plus adding synonyms to keywords helps customers who may not be aligned with a company’s internal vocabulary (which always sneaks into many company’s articles).

      That said, FAQs aren’t obsolete, but they shouldn’t be a primary source of self-service as a company scales their knowledge base. Customers don’t always know the proper vocabulary or must work around an FAQ system like Product Hunt’s or Zappos’ massive list (as of this writing they have no search box). Let’s leave it to the machines to find the right words.

      Edit: type-o

  • Shamim khajamiah

    I love Canada l well like working at Canada please help me submit my Canadian visa l well give you any did and document

Related articles
create-a-knowledge-base-template-from-scratchCustomer experience

Knowledge Base Template: 5 Easy Steps to Create Your Own from Scratch

3-ways-to-politely-reject-customer-requestsCustomer experience

3 Ways to Politely Reject Customer Requests