Write an FAQ

Turn raw support answers into an FAQ phrased the way users actually ask — not the way the company wishes they would.

When to use it

Turning the questions your support team answers on repeat into a page that answers them before anyone has to ask.

What it prevents

The FAQ that answers questions no one has. Left to invent, models produce polished questions the company wishes people asked — “What makes your product so powerful?” The instruction to phrase questions as a real user would, from real support notes, is what keeps it useful.

The prompt

Write a short FAQ section from the support notes below.

### Audience
New users deciding whether to buy, who have three or four practical worries and no patience for marketing.

### Context
The notes are raw answers a support agent gave in chat. Turn the recurring worries into questions a prospect would actually type.

### Requirements
- Output format: Markdown. Three to five question-and-answer pairs, each answer under 40 words.
- Phrase questions the way a user would ask them, not the way the company would.
- Answer the worry directly in the first sentence, then add one detail.
- Avoid: questions no one asked, and answers that dodge the concern.

### Example of the wanted output
**Can I cancel any time?**
Yes, from Settings, and you keep access until the period ends.

### Support notes
"""
People keep asking if cancelling loses their data (it does not), and whether it works offline (mostly).
"""

Why each part is there

Every section of that prompt exists because a specific failure happens without it. These are the checks it passes, and what each one is protecting you from:

• States a concrete task — why this matters
• Avoids vague language — why this matters
• Specifies an output format — why this matters
• Gives context or audience — why this matters
• Avoids dangling references — why this matters
• Includes an example — why this matters
• Separates data from instructions — why this matters
• Avoids over-aggressive phrasing — why this matters
• Defines what a good answer looks like — why this matters

How to adapt this one

Feed it your actual support logs or chat transcripts, and keep the rule that questions are phrased in the user's words, not the company's. Keep the short answer cap; an FAQ answer that runs long has become documentation and belongs elsewhere. The instruction to answer the worry in the first sentence is what makes the page skimmable.

The mistake this prompt avoids

Writing the FAQ from the company's point of view. “Is our platform secure?” is a marketing question; “Can other people see my files?” is the worry underneath it. Users search their fear, not your feature. Phrase the question the way it is typed at 2am, or the person with that worry never finds the answer.

A variation

Building an FAQ to reduce a specific support load? Start from the tickets, not your imagination — ask the model to cluster a batch of real questions into themes first, then write one FAQ entry per theme ranked by frequency. That way the page attacks the volume you actually have rather than the questions you assumed you would get.

Check your version

Once you have adapted it, run it through the checker. The same nine checks that graded this page will grade yours, free and in your browser — paste it in, or build one from scratch by answering a few questions.