The engineering-escalation branch is the part most help docs skip: they turn every recurring question into a workaround, even when the real fix is a bug ticket. If this article ends up feeding an on-site AI chatbot such as AI Engine, keep each section self-contained since chatbots often surface a single paragraph out of context.
Content
Turn recurring support tickets into a real help article
Groups the same handful of paraphrased support questions into one canonical help doc, ordered by how often and how badly they block the customer, not just alphabetically.
Works with Claude / GPT1,400 uses★ 4.4
The prompt
content-faqs-into-help-article
You write documentation for a WordPress security plugin. Support has flagged that 6 variations of the same question show up across roughly 40 tickets a month, all about why the license key won't activate after a server migration. RAW TICKET QUESTIONS (as customers actually phrased them): [ "why does my license say invalid after i moved hosts", "license key not working new server", "do i need a new license key if i change hosting", "reactivating plugin after site migration", "license keeps deactivating itself", "is this a bug or did i mess up the migration"] PRODUCT CONTEXT: [license ties to a site URL/fingerprint, migrations often change it] Work through this before drafting the article: 1. Group these into the actual underlying questions rather than answering all six separately, most of them are the same issue phrased differently, and a help article with six near-identical headers reads as padded and hard to scan. 2. Order sections by how often the question comes up and how blocking it is, not alphabetically. The migration-reactivation issue is clearly the dominant case here, so it leads. 3. Edge case: "license keeps deactivating itself" (repeated, ongoing) is a different problem from a one-time migration mismatch, it may point to a real bug rather than user error. Don't fold it into the same workaround answer, give it its own section and note that it should be escalated to engineering if the workaround doesn't hold. 4. Write each answer as a direct action sequence (what to click, in what order), not a restatement of the question. Assume the reader is frustrated and skimming, not reading for context. 5. Add a short "still stuck?" section at the end with what info to include in a support ticket (site URL, license key last 4 digits, approximate migration date), so tickets that do come in are pre-qualified with the details support actually needs. Draft the full help article with a title, one intro line stating what it covers, and sections ordered as above. Replace the bracketed ticket questions and product context above with your own.