Frequently Asked Questions on websites tend to have a lot in common with the question and answer briefing notes which civil servants have been writing since time immemorial. In both cases, the temptation to write questions which happen to have straightforward answers, rather than the questions which any real people have ever actually asked, is almost overwhelming.
That’s pretty irritating when you are on the receiving end of it – but it’s also remarkably inefficient when you are on the production end. There is nothing to be gained from answering questions which people don’t want to ask, and it certainly won’t stop them finding other ways of asking the questions they do want to ask – they will just find other ways of getting the answer, often at greater cost to you and still more often with greater frustration for the customer.
Kevin Kelly let rip on this a few days ago
Ignoring FAQs is is dumb. Answering real FAQs is smart for several reasons:
- It forces you to face the problem.
- It forces you to face your answer.
- It’s an opportunity to sell (yes).
- It projects your character and brand.
- You can control the answer…
Sure, have an employee write the answers for FAQs. But keep the questions real. Need some real questions? Ask the help desk, or tech support, the mail room, or the receptionist!
You don’t have to answer every question people will have. If you can answer the top 10 real FAQs (per subject) you can change the tenor of your feedback.
This is all good stuff. But there are two reasons why this matters even more:
doing it well requires there to be a direct link between what appears on the website and the questions which customers are actually asking – which means capturing them, understanding them and addressing them. Just having and supporting a process systematically to identify what those questions are is hugely valuable
doing it well can result in some very direct efficiency improvements which flow from customers being able to find out what they actually want to know. Kelly links to an encouraging piece which shows some concrete benefits:
FAQs don’t have that great a reputation, but recently, I’ve been working on FAQs for a client. Their computer help desk was annoyed about answering the same things again and again. Why not divert potential callers to a FAQ instead?
Sounded reasonable, so we did the usual: created a prototype, ran some usability tests, did the necessary pile of changes and launched the revised version, rather quietly. And bingo: a modest success. Calls to the help desk are down 10% and users are rating the FAQ answers highly, on the whole.
That post goes on to set out some of the ways of writing FAQs to be good, not bad, as does this article, with a slightly different set of tips, ending with the splendid final question,
“What if I have a question that isn’t answered here?”