Help-center FAQs fail when they mirror the team’s mental model instead of the user’s words. Search queries, support tickets, in-app questions and forum posts hold the real questions; team-written FAQs do not. These 15 prompts cover question discovery from real data, deflection-aware answers (link to the right place, do not block contact when needed), answer scaffolding patterns, and the structure of a help center that scales without becoming a junk drawer.
Who this is for
Product and CX teams writing or refactoring a help center, founders who answer the same 12 questions every week, support leads trying to reduce ticket volume, and content designers shaping in-product help.
When not to use these prompts
Skip these for legal disclosures, compliance pages, or anything requiring counsel sign-off — FAQs are user-facing copy, not policy. Skip too if you have under 50 weekly tickets — read each one and write answers by hand.
Prompt anatomy / structure formula
A help-center FAQ prompt should always carry six elements:
- Role: who the AI plays (senior PM / solo founder / product designer / indie dev / growth lead).
- Context: stage (idea / MVP / growth / scale), team size, traffic or ARR, platform (web / iOS / Android), audience, constraints.
- Goal: one concrete deliverable — one PRD section, one user-story set, one experiment design, one launch post.
- Constraints: timeline (this sprint / this quarter), scope cuts, must-not-break (existing flows, billing, compliance).
- Output format: table, checklist, ticket-ready JSON, or labeled blocks you can paste straight into Linear / Notion / Jira.
- Examples / signal: 1-2 reference docs or competitors you like, plus 1 anti-example you want to avoid.
Best for
- Net-new help center launch
- FAQ refresh after a feature change
- Top-10 deflection questions for a high-volume topic
- In-product help-tip copy
- Search-query-driven content backlog
15 copy-ready prompt templates
1. Question discovery from support tickets
Run this before writing any answers. Generates the backlog.
You are a help-center content designer. Below are {N} recent support tickets. Extract the 25 most-asked underlying user questions, phrased the way users would type them into search (not how the team phrases them). For each: count, % of tickets, severity. Group into 5-7 topic clusters.
Tickets: {paste}Variables to swap: N, tickets corpus
Optimization: If output looks paraphrased, add: “Each question must use the user vocabulary, not internal product terms. If users say login and we say sign-in, use login.”
2. Question discovery from search logs
Below are {N} internal search queries from our help center. Extract the 20 highest-intent question patterns. Mark each: has a published answer (yes/no), is the answer good (yes/no/unknown). Output as a backlog table.
{paste queries}3. Deflection-aware answer scaffolding
For each of these 5 user questions, write an answer that (a) solves the problem in 80 words or less, (b) links to one deeper resource, (c) keeps a "still need help?" contact path visible but not pushed. Avoid forcing deflection — some questions belong with humans.
Questions: {paste}4. Question-to-answer expansion
Below is a single user question. Write the answer at 3 lengths: (a) 1-sentence quick answer (search-snippet ready), (b) 80-word standard answer, (c) 200-word detailed answer with troubleshooting steps. Use the same vocabulary in all 3.
Question: {paste}5. “Step-by-step” answer template
For procedural questions like "How do I cancel" or "How do I add a teammate", write an answer that uses: (1) 1-line summary, (2) numbered steps (max 7), (3) what to expect after each step, (4) what to do if it does not work. Format as markdown.
Question: {paste}6. “Why does X happen” explanatory template
For "why" questions ("Why was I charged twice?", "Why did my data disappear?"), write an answer that: (1) acknowledges the worry in one line, (2) explains the most likely cause, (3) tells the user the next action, (4) names the rare case it could be something else. Voice: clear, never defensive.
Question: {paste}7. Edge-case branching answer
For this question, the answer depends on user state ({plan tier, OS, account age}). Write a branching answer: 1-line intro, then "If X, do Y" for 3-5 branches. Format so the user lands on their branch within 8 seconds.
Question: {paste}8. Help-center information architecture
Below is our current FAQ list of {N} articles. Reorganize into a 3-level information architecture: top-level sections (5-7), sub-categories under each, individual articles. Mark any article that belongs in multiple places — those become candidates for splitting.
{paste FAQ list}9. Cross-link audit
Below are 10 help articles. For each, recommend 2-3 articles to cross-link based on user journey (where they go next), not topical similarity. Mark any orphan articles that nothing links to.
{paste articles}10. In-product help-tip copy
For these 6 product screens, write the in-product help tooltip + the matching help-center article title. Tooltip: less than 15 words. Article title: question-shaped ("How to {action}"). Output as a 6-row table.
Screens: {paste}11. SEO-aware FAQ rewrite
Below is a help article. Rewrite for SEO without losing voice: H1 as a question matching real search query, first paragraph answers in 40 words, headings break into scannable sections, internal links to 3 related articles. Maintain accuracy.
{paste}12. Failure-mode honesty pass
For each of these 5 FAQ answers, audit for "honesty about failure modes": does the answer acknowledge when the feature does not work, when the user might still need to contact support, when an alternative is better? Rewrite any that hide failure modes.
{paste FAQs}13. New-feature FAQ generation
We are launching {feature} on {date}. Anticipate the 10 most-likely user questions before launch. For each: write a draft answer. Mark questions where the answer depends on undecided product decisions — those go to PM for input.
Feature spec: {paste}14. Multilingual FAQ adaptation
Adapt these English FAQs for {Japanese, Spanish, German, Simplified Chinese}. Rules: do not translate literally — adapt cultural expectations ({formality, directness, contact preferences}). For each FAQ, mark whether it needed full rewrite or just translation.
{paste FAQs}15. Help-center quality dashboard
Design a help-center health dashboard with 8 metrics: total articles, articles updated last 90 days, search queries with no result, top 10 articles by traffic, top 10 articles with low deflection, articles with negative feedback, average response time after FAQ visit, ticket volume per topic before/after FAQ change. Define each metric and the threshold that triggers action.Common mistakes
- Writing FAQs from the team’s mental model instead of from real tickets and search logs.
- Forcing deflection — some questions should still route to a human; pretending otherwise burns trust.
- Long answers with no quick-answer-first structure.
- Mixing procedural and explanatory answer formats for similar questions.
- Linking everything to everything — readers do not navigate, they search.
- Forgetting to update FAQs when the product changes — stale FAQs are worse than no FAQ.
- Translating multilingual FAQs literally instead of culturally adapting.
How to push results further
- Always source the question backlog from tickets + search logs, not team brainstorming.
- Lead every answer with a 1-line quick answer for search snippets.
- Keep “still need help?” visible on every page — pushy deflection backfires.
- Refresh FAQs after every major feature change; stale FAQs cost more tickets than no FAQs.
- Track which articles deflect tickets vs which generate them, and rewrite the latter.
- Use real user vocabulary; if users say “login”, do not write “sign-in”.
- Build a tiny set of templates for procedural / explanatory / branching answers, not one-off prose.
FAQ
- How many articles should a help center have?: Quality over quantity. 50 well-written articles beat 200 mediocre ones. Cull aggressively.
- Should the FAQ replace human support?: No. It should deflect the repetitive 60-70%. Routing the remaining 30-40% to humans is the design goal.
- How do I know if an FAQ is working?: Track tickets-per-topic before and after the FAQ exists. If volume drops by 20%+ and CSAT holds, it works.
- Can AI write the entire help center?: It can draft, but every answer must be reviewed for product accuracy and tone before publishing.
- How often should I refresh content?: Every feature change for affected articles, plus a full audit every 6 months for the top 20 articles by traffic.