The short answer
An FAQ page fails to deflect questions not because customers refuse to read, but because finding an answer on it is work the customer has to do: locate the page, scan for their topic, and translate a general policy into their specific case. An answer delivered in their own words, at the moment they are stuck, removes all three steps.
You did the responsible thing. You wrote an FAQ page covering the fifteen questions you were tired of answering, linked it in the footer, and waited for the inbox to quieten down. It did not. The same fifteen questions still arrive, in the same volume, and now you also maintain a page.
The usual explanation is that customers do not read. That is unfair and, more importantly, it is not what is happening.
What you are actually asking the customer to do
Follow the path from question to answer as it exists today. A customer is on a product page at 10pm and wants to know whether the item ships to their pincode before the weekend. To get that from your FAQ, they must: notice the FAQ exists, find the link, load the page, scan a list of questions for one adjacent to theirs, open it, read a general policy, and then translate it into their specific case.
That is seven steps, and the last one is the killer. Your policy says 'metro cities 2-4 days, rest of India 4-7 days'. Their question was about their pincode and this weekend. The page contains the raw material for the answer but not the answer, and at 10pm nobody does that arithmetic on your behalf.
Sending a message takes one step. Given a seven-step route and a one-step route to the same information, people take the one-step route. That is not laziness - it is the correct decision.
An FAQ page holds answers. It does not deliver them. Those are different products, and only one of them reduces your inbox.
The three failures, in order
| What goes wrong | Why | What fixes it |
|---|---|---|
| They never reach the page | It is a destination, not an answer | Answer where the doubt occurs |
| They reach it and don't find their question | Their wording differs from yours | Match on meaning, not headings |
| They find it and it doesn't resolve their case | Policy is general, questions are specific | Apply the policy to what they asked |
The second row is worth dwelling on because it is invisible to you. Your heading says 'What is your return policy?'. The customer is thinking 'size chota hai, change ho jayega?' - the same question, no shared words. A page organised by your phrasing is only searchable by people who already phrase things your way, which is mostly people who work at your company.
Why the search box doesn't rescue it
The usual next move is to add a search box to the help centre. It helps a little and it inherits the same problem: most site search is keyword matching, so it fails on exactly the queries that needed help - different wording, mixed languages, a question spanning two topics.
It also still requires the customer to be on the help centre. You have improved step five of a seven-step journey most people abandoned at step two. The difference between keyword matching and meaning-based retrieval is the whole of why one deflects and the other does not.
What to do with the page you already wrote
Do not delete it. It earns search traffic, it reassures browsers who are evaluating you, and - most usefully - it is the fastest first document your knowledge base will ever get. Paste it in and you have covered your most-asked questions in about two minutes.
But read it once before you do, because FAQ pages accumulate marketing sediment. Answers that say 'we pride ourselves on quick dispatch' instead of 'orders placed before 2pm ship the same day' state nothing a customer or a retrieval system can use. Strip each answer down to its facts, split multi-part answers into one question and one answer, and you end up with two documents doing two different jobs: one that persuades a human browsing your site, and a shorter one that answers a query. The knowledge-base guide covers how to structure the second.
Answer where the question happens
The change that actually moves the ticket count is not editorial, it is positional. The questions get answered at the point of doubt instead of on a page the customer has to go and find.
That means the product page, where sizing and delivery questions occur. The cart, where an unanswered doubt becomes an abandonment. And the policies page itself, because a customer reading your returns policy demonstrably has a returns question - answering it in their words beats making them parse yours.
The answer they get is the same fact from the same document. What changed is that it arrives in one step, in their phrasing, applied to their case, at 10pm. That is the version that stops the message being sent.
How you will know it worked
Two numbers, both of which you can read a fortnight after the change. The share of conversations resolved without a person should climb, and it should keep climbing for a month or two as you close gaps. And the questions that still reach you should get less boring - if 'what's your return window?' is still arriving in your inbox, the answer either is not in a document or is not written plainly enough to retrieve.
That second signal is the useful one, because it is specific. Every question the agent could not answer is logged, and that list is the next paragraph you owe your customers. The metrics post covers what else is worth counting, and the free plan is enough to test the premise using the FAQ page you have already written.
Frequently asked questions
Why don't customers read the FAQ page?
They usually do not find it. The FAQ is a destination, and a customer stuck on a product page at 10pm is not looking for a destination - they are looking for one answer. Every navigation step between the question and the answer loses people.
Should I delete my FAQ page then?
No. Keep it - it earns search traffic and reassures browsers. Just stop expecting it to reduce tickets on its own, and use its content as the first document in your knowledge base so the same answers reach people where they actually get stuck.
What makes an FAQ answer hard to reuse?
Marketing language. 'We pride ourselves on fast delivery' states nothing checkable. Rewriting each answer down to its facts - the window, the number, the condition - makes it both a better page and a retrievable document.
Where should answers appear instead?
At the point of doubt: the product page, the cart, and the policies page. A question asked where it arises gets answered before it becomes a ticket or an abandoned cart.
