A FAQ page is usually written once, by someone who already knows the product, in the vocabulary the company uses internally. Then it is never touched, while the questions customers actually ask drift somewhere else entirely — into support tickets, chat transcripts and the notes a salesperson keeps on their desk.
The result is a page that answers the questions the company wanted to answer. It ranks for nothing useful, it converts nobody, and it exists mainly so that a link can be pointed at it. A working FAQ is built the other way round: from real questions, in the customer's words, sorted by when they occur.
Where the questions come from
You almost certainly already have the raw material, and it is not in your analytics. Look in four places: the last hundred support tickets, sorted by volume; the questions salespeople answer on calls, which are usually objections rather than questions; the search queries that brought people to pages that did not answer them; and the questions asked right before someone abandoned a purchase.
Collect them verbatim. Not "pricing concerns" but the actual sentence, including the typos, because the phrasing is the asset. When you write the heading later, the customer's wording is what makes the page findable and what makes the answer feel like a reply rather than a policy.
If you have no ticket history — a new product, a small audience — the second-best source is the questions you find tedious to answer in email. Tedium is a reliable signal that a question recurs.
The four question types
Questions cluster into four kinds, and they belong on different pages or clearly separated sections, because they serve different readers at different moments.
- Fit. Is this for someone like me, and is it for my situation?
- Mechanics. How does it work, what does it need, how long does it take?
- Commercial. What does it cost, what is included, what happens if I stop.
- After the purchase. How do I get in, how do I fix it, how do I change or cancel it.
Mixing all four into one alphabetical list is the most common structural mistake, because a reader deciding whether to buy has to scroll past account-recovery instructions to find the price. Group by moment — before, during, after — and keep the ordering deliberate.
Answering before the purchase
Pre-purchase questions are where a FAQ earns or loses money, and the temptation is to answer them in marketing language. That fails, because someone asking a pre-purchase question is looking for a disqualifying fact, not reassurance.
Answer with the specifics that let the reader rule themselves in or out. If the product suits teams of two to ten, say that, and say what happens at eleven. Being clear about who it is not for increases trust and reduces refunds, and the reader who leaves was going to be a bad fit anyway.
Answer the price question directly, before the objections. An answer that opens with value framing and hides the number reads as evasion, and readers who feel handled stop reading. If the pricing is genuinely complicated, describe the shape — what it depends on and roughly what range it lands in — rather than deflecting.
Answering after the purchase
Post-purchase questions are different in kind: the reader is already committed, mildly frustrated, and wants a specific action. Write these as instructions, not explanations, and put the action in the first sentence.
Order them by frequency, not by the order in the interface. The most common post-purchase question should be first even if it feels like a basic one, because the reader who needs it is the reader who is currently stuck. Link out to the detailed documentation rather than pasting it, but keep the four-line version on the page — people should not have to leave to get unstuck.
Re-read this section every quarter against your ticket volume. It is the part of the page that goes stale fastest, because most post-purchase friction comes from interface changes, and whoever ships the change rarely remembers the FAQ exists.
Answers without marketing
Two habits ruin otherwise good answers. The first is the deflection: a heading that asks a direct question, followed by three sentences that restate the question and never answer it. If the answer is unfavourable, give the unfavourable answer, then whatever context helps. That is more useful, and it is less likely to generate an angry support ticket.
The second is the trailing pitch, where every answer ends with a sentence about how easy the product makes it. One reminder is tolerable; fifteen is a pattern that makes readers discount everything you have written. Keep the sales argument in your landing page, where the reader expects it, and let the FAQ be the place where the reader finds out the truth.
Length and structure
Aim for answers of two to four sentences. Long enough to settle the question, short enough that the reader can scan to the next one. If an answer needs more than a short paragraph, it is a support article, and the FAQ entry should be a two-sentence summary with a link.
Write headings in question form using the customer's wording, and keep them as close to spoken language as you can stand. "Can I use it on two computers" will outperform "Multi-device licensing policy" for every audience except procurement officers, and even they will not be confused by the plain version. Keep a table of contents at the top once you pass about a dozen questions; below that it is clutter.
Using AI without inventing facts
AI is genuinely useful here, but only for two jobs. It can cluster a hundred verbatim questions into groups and name them, which is a sorting task you would otherwise put off. And it can turn an answer you have written in bullet points into readable prose.
It must not generate the answers. Asked to write a FAQ, a model will produce confident, specific, plausible policies — eligibility thresholds, refund windows, supported file types — that have no connection to what your product actually does. Every one of those sentences is a commercial commitment you will have to honour or correct publicly.
So the order is fixed: gather real questions, write the answers yourself from what you know to be true, then use the model to group, tighten and de-duplicate. Check the final page against the product once, line by line. It takes twenty minutes and it prevents the specific kind of mistake that undermines the whole page.
Keeping the FAQ alive
A FAQ is not a document, it is a filter. Give it a monthly slot: add the questions that appeared more than twice, delete any question nobody has asked in six months, and re-check the post-purchase section against the latest release. The count should stay roughly stable, which is the sign that entries are being retired as fast as they are added.
The signal that the page is working is not traffic. It is the disappearance of a question from your support queue, and the appearance of one you had not thought of. When the page stops producing new questions, you have stopped reading the right source.