FAQ

A team that has just launched answers support mail one message at a time. Five a day is manageable — open the inbox, write five replies, done. The trouble starts when three of those five are the same question somebody already answered yesterday.

Early on at Pagedeck, Sofia was writing the reply to "where do I change my payment card?" for the seventh time. Rewriting it from scratch felt wasteful, so she dug through her sent folder to copy an older one, which took ten minutes on its own. Worse, the seven replies were not identical. Some mentioned when the next charge would land after a card change and some didn't, so a customer who got the shorter version came back a few days later asking exactly that.

The wasted typing is the smaller problem. The bigger one is that answers written fresh every time drift between people, and drift within one person. So the repeated questions get pulled out, the answer gets settled once, and everyone points at that document instead. When the answer changes, there's a single place to change it.

In support operations this document belongs to the self-service branch — the tools that let a customer find the answer without a person in the loop. It isn't about handling incoming requests faster; it's about keeping them from being filed at all. That's why the number it moves is ticket deflection, the share of customers who find an answer on their own and never open a request.

One entry is a question, an answer of two or three sentences, and one next step. Those three pieces travel together, and the document is a set of those entries grouped by topic.

1. The question — written in the words customers actually use. Not "billing method policy" but "how do I change my payment card?" Customers don't know the internal name of a feature, so a title built from product vocabulary hides an answer that is sitting right there.
2. The answer — two or three sentences and out. Lead with background or edge cases and the reader quits on line three and files a request anyway. Put the conclusion first and hang the exception off the end in one line.
3. The next step — a link to the billing screen, a request form, a button that opens a conversation. Without this line a customer reads the answer, doesn't know where to go with it, and files a request anyway.

Two more fields exist for the people maintaining the page rather than the people reading it. A category groups questions by topic: billing, account, permissions — five or six labels is plenty, and splitting into twenty just makes the reader choose a drawer before they can look. A last-reviewed date and an owner record when each entry was last checked and who to tell when it's wrong.

Order is part of the structure too. Entries go in order of how often the question arrives, not alphabetically and not in the order the product menus are arranged. Counting last month's support tickets — the individual filed requests, each with a number, an owner and a status — usually shows the top ten questions accounting for more than half the volume. Put those ten at the top and half of your readers get their answer without scrolling.

The person who writes it is the one taking the requests, and the person who checks it is the one who built the feature. Support writes because only support knows the words customers use. Engineering checks because only engineering knows the exceptions. An engineer writing alone produces something accurate that nobody can find by search; a support rep writing alone produces something readable that quietly carries a wrong answer for six months.

There are three readers.

1. Customers, who open the page and read it. They are the intended audience.
2. Support reps, who paste entries into replies. The macros a team saves for common answers usually lift their wording straight from this page, so editing the page means editing the macros or the two start disagreeing. A chatbot, which answers in the chat window without a person, reads the same entries to pick its replies.
3. Search engines. A question-shaped heading followed by a short answer is close to the ideal shape for a featured snippet, the box that lifts an answer to the top of a results page. A well-kept page cuts support cost and pulls in search traffic at the same time.

"This came in twelve times just this week. Should it go on the FAQ?"

The request log shows the question repeating, so it should become an entry instead of something a person answers each time.

"It's on the FAQ, but nobody seems to find it."

The answer exists, and the heading is worded differently from what customers type, so search never surfaces it.

"The policy changed, so let's fix the FAQ before the announcement goes out."

The page is where the answer lives; skip it and support replies and the announcement will say different things.

Once a month at Pagedeck, Sofia and Mia sit down with the previous month's requests. Sofia brings the ten most frequent questions and Mia sorts them on the spot into two piles: questions a document can close, and questions that only disappear if the product changes. "Why did my invite link expire?" lands in the first pile and becomes an entry that day. "I can't find the save button" lands in the second and becomes a product task.

The first assumption is that a longer page is a better one. Cover every possible question and every customer finds an answer — reasonable on its face. In practice each added entry lowers the odds that a reader finds theirs. Faced with thirty headings, people scan, give up, and file a request. Left alone, the page keeps growing while the request volume doesn't move, and reps keep answering questions that are already written down. Cut the list at the most frequent entries and move the rest into longer topic articles.

The second is that this page can paper over a product problem. If customers get lost, explain better — a natural enough instinct, but it reads backwards. A question arriving a hundred times a month is evidence that a screen fails to explain itself. Writing the entry makes that evidence disappear from the numbers, so the thing worth fixing never gets found and the explanations pile up instead. Teams that handle this well log a product task alongside every new entry they publish.