Support Reply to Public FAQ Flow

A public FAQ candidate checklist helps a small team decide whether a support answer should become a searchable public record. The goal is not to publish every reply. The goal is to identify answers that reduce repeated work while keeping private cases private.

Start with repeatability. If three customers ask the same question in slightly different words, the answer probably belongs in a public FAQ. Examples include delivery range, pickup timing, refund window, booking change policy, product care, invoice request steps, supported payment methods, allergy handling, or how a membership pause works. A repeated rule is a strong candidate because future visitors can self-serve before opening a ticket.

Next check whether the answer depends on a specific customer. If the reply includes order status, health information, payment history, address details, staff notes, photos from a complaint, or account recovery evidence, it should not be published. Even if the public would benefit from the general rule, the individual evidence must be removed before anything becomes public.

Then separate policy from exception. A reply that says “we normally do not refund opened items, but we made an exception because the seal was damaged before delivery” should not become a public promise. The FAQ can explain the normal refund rule and how to report damaged delivery. The exception stays private.

Finally, ask whether the answer will age well. Public FAQs should be stable enough to survive pricing updates, staff changes, and seasonal operations. If an answer depends on this week’s inventory or one employee’s judgment, it may be better as a private reply or short Hub Post discussion rather than a durable FAQ.

A useful checklist is: repeated question, stable rule, no personal data, no one-off concession, clear next step, and easy wording. If one of those fails, keep the reply private and only extract the general lesson later.

Public FAQ Candidate Checklist

// COMMENTS

ON THIS PAGE