A resolved support ticket contains more than an answer. It captures the customer's vocabulary, the symptom they noticed, and the explanation that helped them move forward. This first-run checklist turns that material into help-center entries without publishing private details or presenting a one-off workaround as product guidance.
1. Pick one recurring support problem
Start with a narrow issue that appears across several resolved tickets, such as an API authentication error after a key change. Avoid grouping every authentication question together: an expired key, a missing header, and an incorrect endpoint may need different instructions.
Choose tickets with a confirmed resolution, then record the shared symptom, affected product area, and successful fix. Exclude unresolved cases and answers that depend on an account-specific exception. Your first deliverable is one clearly bounded documentation candidate, not a backlog-wide rewrite.
2. Remove private details before drafting
Build a sanitized working copy before sending ticket content to any model. Remove names, email addresses, access tokens, payment details, internal notes, and customer-specific identifiers. Replace necessary examples with invented values that cannot authenticate or identify anyone.
- Keep: the error message, relevant product behavior, and verified troubleshooting steps.
- Remove: credentials, raw request payloads containing personal data, and unrelated conversation history.
- Preserve separately: restricted references to source tickets so reviewers can check the evidence.
Check screenshots and attachments too. Redacting the conversation text does not sanitize a log file attached to it. Follow your organization's data-handling rules and confirm that any external processing is approved.
3. Build an evidence brief from resolved cases
Give the drafting process a compact evidence brief rather than an entire conversation export. Include the reader's goal, recognizable symptoms, prerequisites, confirmed cause, resolution steps, and known limitations. Mark uncertain information explicitly.
Separate product facts from agent suggestions. A support reply saying “try creating another key” does not prove that key rotation is the documented fix. When tickets disagree, check the current product behavior or ask the responsible team before writing instructions.
4. Draft the entry with a constrained prompt
An AI model can turn the brief into a consistent first draft. SwiftRelay is a practical option for this drafting stage when your approved workflow uses an OpenAI-compatible SDK. Sign up for SwiftRelay to try the workflow with the small gift credit available to new accounts, then use a model such as Claude Sonnet 5.5 with sanitized material.
For an OpenAI-compatible SDK, configure the base URL as https://api.fastapirelay.com/v1 and keep credentials in environment variables. Keep ticket collection, sanitization, and publication outside the model's control.
Drafting prompt: “Write a help-center entry using only the supplied evidence. Include a symptom-based title, who this affects, prerequisites, numbered resolution steps, a verification check, and an escalation path. Do not invent interface labels, commands, causes, or policies. Flag missing information for review rather than filling it in.”
5. Test every instruction against the product
Treat the draft as unverified documentation. Have a reviewer follow its steps in a safe test environment using the permissions a customer would actually have. Check interface labels, command syntax, prerequisites, and any actions that could delete data or interrupt an integration.
Add a concrete success check, such as confirming that an authenticated test request succeeds. If the steps fail, tell readers what non-sensitive diagnostic information to collect and where to contact support. Never ask them to send a secret key.
6. Publish where customers will search
Use the customer's symptom in the title and opening paragraph. Replace internal shorthand with terms readers recognize. Add relevant category placement and search synonyms, then link the entry from the support reply template used for that issue.
Assign an owner and record the review date. Publish only after technical and editorial approval; a polished draft is not evidence that its instructions are correct.
7. Feed article outcomes back into support
Tag future tickets that match the entry and note whether the article resolved the question. Track repeated clarification requests, unsuccessful searches, and steps customers still misunderstand. Ticket volume alone cannot show whether an entry helped.
Use those signals to revise the article or split it into narrower entries. The finish line is a maintained answer that customers can find, follow, and verify—not simply another published page.