Verified against ChatGPT · 2026-08-11
Turn one resolved ticket into a knowledge base article without leaking the customer's specifics
Converts a single resolved support ticket into a general-purpose knowledge base article, stripping the specific customer's account details while keeping the actual troubleshooting logic intact.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are writing a knowledge base article generalized from one resolved support ticket. The article needs to help any future customer with the same issue, not just document what happened to this one. RESOLVED TICKET Customer's exported invoices were missing tax line items; caused by a regional tax setting defaulting to 'not applicable' after a plan downgrade; fixed by resetting the tax region in Settings > Billing > Tax, no backend intervention needed. ARTICLE CATEGORY Billing & Invoicing RELATED EXISTING ARTICLES (to avoid duplicating) 'Why is my invoice missing tax?' exists but only covers the case where tax ID wasn't entered at all, not the downgrade-reset scenario. STYLE GUIDE Short paragraphs, numbered steps for anything actionable, no first-person 'I' language since this isn't a personal reply. HOW TO GENERALIZE THIS Strip every detail specific to this one customer — account numbers, exact dates, names, order IDs — and replace them with the general condition that made this issue happen, so the article reads as "if X is true for your account, do Y," not "this is what happened to customer #4471." Preserve the actual diagnostic logic from the ticket: what confirmed the cause, not just the final fix, since a future customer or agent may need to verify the same cause applies before following the same steps. Write the title as the actual symptom a customer would search for, matching how it appeared in the original ticket's language, not a formal internal name. If 'Why is my invoice missing tax?' exists but only covers the case where tax ID wasn't entered at all, not the downgrade-reset scenario. shows this overlaps significantly with an existing article, say so and suggest whether this should be a new article, a section added to the existing one, or skipped as a duplicate — do not silently create a near-duplicate article. WHAT NOT TO DO Do not include any step from the ticket that only worked because of a manual backend fix an agent applied (like a support engineer manually resetting something in the database) unless the article also tells the reader this step requires contacting support rather than presenting it as self-service when it isn't. OUTPUT FORMAT 1. Suggested title (search-phrase style). 2. The article: symptom description, cause, resolution steps, marking clearly which steps are self-service vs. require contacting support. 3. A note on overlap with 'Why is my invoice missing tax?' exists but only covers the case where tax ID wasn't entered at all, not the downgrade-reset scenario. and a recommendation (new / merge / skip).
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
The core risk in generalizing a real ticket with GPT-5.1 is that it tends to preserve specific-sounding details as color rather than recognizing them as customer-identifying information to strip, since nothing in the raw ticket text marks which details are structural (the cause) versus incidental (this particular account) — the explicit instruction to separate the general condition from the specific instance is what makes that distinction happen reliably instead of leaving account numbers or names in a published article by omission. Preserving the diagnostic logic rather than only the final fix matters because a knowledge base article that just says "reset the tax region" without explaining what confirms that's the actual cause will get applied by future agents or customers to cases where the symptom looks similar but the underlying cause is different, silently degrading the article's accuracy over time as it gets used for cases it wasn't actually written for. Flagging steps that only worked because of a manual backend intervention addresses a common and quietly harmful KB failure mode: an agent resolves a ticket by doing something in the admin panel a customer can't access, that gets written up as a numbered self-service step, and every future customer who tries to follow it hits a wall and files a new ticket anyway — worse than not having the article, since it wastes their time with false confidence. Checking for overlap against related articles before generating new content is necessary because GPT-5.1 has no visibility into what already exists in your KB unless told, and will happily produce a plausible near-duplicate that fragments your documentation and search relevance instead of consolidating into the entry that should be the canonical one.
What you get back
Title: Why is tax missing from my exported invoices after changing plans? Symptom: Invoices exported after a plan change show no tax line items, even though tax was applied correctly before. Cause: Plan downgrades can reset your account's tax region setting to 'not applicable' as a side effect of the downgrade process. Self-service fix: Go to Settings > Billing > Tax and re-select your correct tax region. Re-export the invoice after saving. Overlap note: 'Why is my invoice missing tax?' covers the case where a tax ID was never entered — this is a distinct downgrade-triggered cause. Recommend adding this as a second cause section in that existing article rather than a standalone one, since customers searching either symptom will land on the same query.
Verified against
ChatGPT GPT-5.1 · 2026-08-11
Changelog
- 2026-08-11 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
