Turn a pile of support tickets into a searchable FAQ draft

Step 1: Export a clean sample

Pull a recent slice you can stand behind:

• Last 30–90 days of tickets (or a random sample if volume is huge)
• Fields: subject, body, resolution note if you have one, product area tag
• Strip or redact customer names, emails, order IDs, payment details before any paste into tools

Redact first. Clustering second.

Step 2: Cluster themes without writing answers yet

Prompt pattern:

Cluster these redacted tickets into themes.
For each theme: name, example subjects (3), rough count, whether resolution notes agree.
Do not write public FAQ answers yet. Mark conflicting resolutions as [CONFLICT].

You want a map of repeated pain—not pretty prose.

Step 3: Draft FAQ only for themes you own

For each stable theme with a clear internal resolution:

Draft one FAQ item: Question (customer words), Short answer, When to contact support instead.
Use ONLY the resolution notes and policy blurbs I provide.
If policy is missing, write [NEED policy]. Do not invent timelines or refunds.

Paste the real policy lines. The model formats; you supply truth.

Step 4: Human review gates

Before anything goes public:

• Support lead checks factual accuracy
• Someone who owns policy checks promises
• Tone check against your voice card
• Link check (help center URLs, status page)

No gate, no publish. Speed without gates creates new tickets.

Step 5: Publish where search happens

Put approved FAQs where customers already look:

• Help center
• In-product help
• Support macros / canned replies
• Optional public blog only if the answer is truly public

Name versions with dates. Retire stale answers when policy changes.

Keep the loop alive

Weekly or biweekly:

1. Pull new tickets tagged “FAQ miss”
2. Cluster only the misses
3. Update or add FAQ items
4. Note which macros still contradict the FAQ

A FAQ that never eats new tickets becomes fiction. For ops review habits, see weekly AI ops review.

What not to automate

• Legal threats and chargeback disputes
• Safety / abuse edge cases without a human
• One-off enterprise contract terms
• Anything that needs account-specific data to answer

Those stay ticket workflows with people.

Worked example (pattern only)

Fifty tickets mention “change my booking time.” Resolution notes agree: self-serve link + 24-hour cutoff. The draft FAQ cites that cutoff because you pasted it. Ten tickets mention “custom refund.” Notes conflict. Those stay [CONFLICT] until policy owns a sentence—no public FAQ yet.

Metrics that matter

• Share of tickets matching an FAQ theme
• Time to first response on those themes after FAQ ships
• Correction rate (how often you edit the FAQ after publish)
• New themes rising this month

Skip vanity like “number of AI drafts generated.”

How a five-person team runs this week

Export and redact a manageable ticket sample on Monday. Cluster themes on Tuesday without writing public answers. Wednesday: draft FAQ only for themes with clear policy text. Thursday: support + policy gate. Friday: publish two or three items max and tag new tickets that still miss. Resist shipping a twenty-item FAQ in one burst—accuracy beats coverage theater.

Pair with voice and email habits

FAQ answers should match the same voice card you use for support macros and outbound mail. If the FAQ sounds like a different company than your email drafts, customers feel the seam. Reuse the approved voice file; do not let FAQ drafts invent a warmer, promise-heavier brand.

Macro alignment

After FAQ items publish, update the matching support macros the same week. Customers hate a help-center answer that disagrees with the reply they just received. If macros and FAQ diverge, the FAQ is not done.

Short close

Cluster, draft from real policy, gate with humans, feed misses back weekly—that is tickets to FAQ without inventing answers.