Create KB Articles from Resolved Ticket Threads

Workflow area: Customer Support · Tier: Core · Hands-on time: ~30 minutes

The economics are simple: an agent resolution costs minutes every time; a KB article costs minutes once. The reason KBs stay thin anyway is that writing an article from a messy thread — reconstructing what actually fixed it from six back-and-forth messages — is exactly the kind of tedious synthesis agents skip at the end of a shift. That synthesis is AI's sweet spot. Your job is picking threads worth documenting, verifying the fix is the real fix, and keeping one human review before anything goes public.

When to use — and when not to

• Use it on tickets that took real figuring-outif the resolution surprised the agent, it will surprise the KB's readers too.
• Use it on repeat questions with no articleanything asked three times deserves a page; check your macro list (pb-33) for types with volume but no self-service coverage.
• Use it after releases and incidentsthe week after a feature ships or an outage ends is a rich vein of undocumented answers.
• Skip one-off edge casesan article about a problem one customer will ever hit is KB clutter that buries the useful pages.
• Skip workaround-as-fix documentationif the thread ends with "restarting fixed it," that's a symptom log, not a resolution. Confirm the root cause with whoever owns the product area before publishing it as truth.

The recipe

1. 1.

   Pick the threads. Pull 5–10 resolved threads worth documenting: solved-after-effort, repeat topics, or post-release questions. Strip customer names, emails, account IDs, and any credentials or URLs containing tokens before they leave the helpdesk.

2. 2.

   Extract one article per thread.

   Copy

   Convert this resolved support thread into a knowledge-base
   article. Audience: customers helping themselves (not agents).
   
   Structure:
   1. TITLE: how a customer would search for the problem, symptom
      first (e.g. "CSV export downloads empty file"), under 70 chars
   2. SYMPTOM: what the user sees, in their words — 2-3 lines
   3. CAUSE: why it happens, one plain-language paragraph, no
      internal system names customers won't know
   4. FIX: numbered steps in the exact order that resolved this
      ticket. Each step = one action + what the user should see
      after doing it.
   5. IF THIS DIDN'T WORK: 1-2 lines on the next step (contact
      support with what info)
   6. PREVENTION: how to avoid recurrence, if the thread supports it
   7. INTERNAL FLAGS (not for publication): anything in the thread
      that was case-specific and should NOT be generalized; any
      step you inferred rather than saw stated in the thread —
      mark each [INFERRED].
   
   Thread (customer details removed):
   [PASTE THREAD — include the agent's final confirmation message]
   
   Rules: use only what the thread supports. If the thread never
   states the cause, write "CAUSE: unconfirmed" — do not invent a
   plausible one. Keep reading level simple; no blame ("you
   incorrectly configured...") — neutral phrasing only.
   

3. 3.

   Verify the fix path. The [INFERRED] flags are your review list. Good output makes review fast:

   Copy

   FIX:
   1. Open Settings → Integrations and select the calendar
      connection. You should see a "Reconnect" button in red.
   2. Click Reconnect and approve the permissions prompt. The
      status badge changes to "Active" within a minute.
   3. Retry the sync from the dashboard.
   INTERNAL FLAGS:
   - Step 2's one-minute timing was this customer's experience —
     [INFERRED] as typical.
   - Thread mentions the customer was on the legacy plan; steps
     unverified for current plans.
   

   Walk the steps yourself in a test account where possible; where not, have the resolving agent confirm with a thumbs-up. An article with confident wrong steps is worse than no article — it burns trust in the whole KB.

4. 4.

   Deduplicate against the existing KB. Paste your current article titles (or export the index):

   Copy

   Here are our existing KB article titles: [PASTE LIST]
   For each new draft, tell me: NEW (no overlap), MERGE (mostly
   covered by [existing title] — list what the new draft adds), or
   REPLACE (existing article is outdated per the new thread).
   

   For MERGE cases, ask for just the delta paragraphs to add to the existing article — two half-articles about the same problem is how customers end up filing tickets anyway.

5. 5.

   Publish with ownership metadata. In Notion (or your KB tool), add per article: source ticket ID, verified-by, verified date, product area, review-by date. Route drafts through whoever owns support content for one approval pass — AI wrote it, an agent verified it, an owner approved it.

Make it yours

• Weekly batch habit: end each week by feeding the 3–5 "hardest solved" tickets through the pipeline — 20 minutes, and the KB compounds instead of decaying.
• Agent-facing twin: ask for a second internal version of each article that keeps the system names, logs to check, and admin steps — same thread, two audiences, one pass.
• Deflection loop: after a month, check which new articles get traffic and which ticket types dropped; feed titles that get zero search hits back to the model — "rewrite these titles as the questions customers actually type."

Quality check

• Steps were walked by a humanor explicitly confirmed by the resolving agent; every [INFERRED] flag got resolved.
• The cause is stated only if known"unconfirmed" beats plausible fiction in a public doc.
• No customer-specific residueplan names, config details, or quoted messages that identify the original case are gone.
• Dedup ran against the real indexevery article is NEW, a MERGE delta, or a REPLACE, decided deliberately.
• Ownership metadata existssomeone's name and a review date are on every published page.