THE SHORT ANSWER
Keep the real question without personal details, get the answer confirmed and put it where someone needs it. A separate FAQ page is optional. A usable answer is the point.
Keep the question, not the customer record
Write down the question in ordinary language. Do not copy a customer's full email into a public content plan. Names, order information and personal circumstances usually have no role in a general website answer.
Ask the people handling inquiries to note the questions they receive in their own work. Do not invent examples and later describe them as things clients asked. A hypothetical question can support planning, but it has to remain hypothetical.
Keep the question's context. Somebody asking what to bring to an appointment needs different information from somebody deciding which service to book. Similar wording does not always mean the same uncertainty.
You can collect this in a simple working note. A question, its context and the person best placed to answer it are enough to begin. There is no need to buy a content tool before writing down what the team already knows.
Get an answer the business can stand behind
Ask the person responsible for the process to approve the answer. Some questions involve a real exception or condition. Explain it instead of writing a confident sentence that is only true most of the time.
An owner might need to explain what information is required before preparing a quote. That is a planning example, not a claim about your company. The actual requirements and any promised deadline must come from the business.
Give changing details an owner. Link to the maintained pricing page rather than repeating a price across articles that may later become inconsistent. Your Page's current scope and terms belong on our pricing page.
Keep the approved source note with the website copy. When the process changes, somebody should be able to work out which answer needs checking without reconstructing an old conversation from memory.
Put the answer beside the decision
If it concerns a service, start with that service page. If it concerns completing a form, put the instruction beside the relevant input. Do not make someone search an unrelated page for a basic requirement.
W3C's form guidance recommends explaining required inputs and useful formats. Applying that here means instructions should be available while someone completes the task, not hidden in a general background article.
Read the answer out loud. Use the actual action or condition instead of jargon. Define an unavoidable technical term once. The customer should not have to learn the business's internal vocabulary to understand what happens next.
Not every answer needs a sales message. Sometimes the accurate answer is that a service is not offered or that a particular condition needs checking. Do not turn that into a reassuring promise you cannot support.
A useful answer may fit in one paragraph. Save longer articles for questions that need explanation, tradeoffs or steps. Extra words are not evidence that the page does a better job.
Check it with somebody who needs the answer
Ask a person unfamiliar with the process to find the information and explain what they would do next. Note the point that remains unclear. That gives the next revision a specific target instead of a general wish for better copy.
Google's helpful-content guidance focuses on serving the intended audience and giving a useful answer. A collection of FAQ headings is not a promise of better search rankings. Choose the question because the reader needs it.
Recheck answers when the business changes a service, booking process or condition. Retire information that is no longer accurate, even if it once attracted attention. A popular wrong answer is still a wrong answer.
Keep the maintenance note simple: the question, approved answer, where it appears, who owns it and when it needs another check. That gives whoever updates the website something they can actually follow.