Every resolved ticket is a knowledge article nobody had time to write. An LLM can draft a KCS-structured article from the ticket's work notes in under a minute — the discipline is the gate: nothing publishes until a technician who did not write the fix has verified that the documented steps actually work.
Tier: Core · Workflow area: Knowledge management · ~30 minutes
This playbook turns your resolved-ticket stream into a steady flow of Issue / Environment / Cause / Resolution articles, using ServiceNow Now Assist KB generation or a plain LLM prompt, and installs the review gate that keeps the KB from filling with confident, untested fixes.
Pick the article template once. Standard KCS shape: Issue (user-visible symptom in user words), Environment (product, version, OS, context), Cause (root cause in one or two sentences), Resolution (numbered, executable steps), plus metadata (keywords, audience, review date). Put it in your KB platform as the mandatory template.
Select factory candidates weekly. Filter resolved tickets: reassignment count low, resolution notes non-empty, category in scope. Then keep only issues seen more than once — repeat count is your signal that an article will pay rent.
Draft with the generation prompt. In ServiceNow, use Now Assist's KB article generation from the resolved incident. Anywhere else:
Write a KCS knowledge article from this resolved ticket.
Structure exactly:
## Issue — symptom as the user would describe it (their words, not ours)
## Environment — product, versions, OS, relevant config
## Cause — root cause, 1–2 sentences; write "Not established" if the
notes only show a workaround
## Resolution — numbered steps a Tier-1 tech can follow verbatim,
including exact menu paths and commands from the notes
## Keywords — 8–12 terms including the user's phrasing and error text
Rules:
- Use ONLY facts present in the ticket. Mark anything you had to
assume as [VERIFY].
- Remove all names, usernames, hostnames and other identifiers.
- If the notes do not contain enough for executable steps, say so
instead of inventing steps.
Ticket: [paste subject, description, work notes, resolution notes]
Expect and use the [VERIFY] markers. A good draft from thin notes looks like:
## Cause
Cached credentials referencing the old file server [VERIFY — notes
say "cleared creds, worked" without naming which entry].
## Resolution
1. Open Credential Manager > Windows Credentials.
2. Remove entries for [VERIFY: old server name].
3. Reconnect the mapped drive; authenticate with current password.
Markers are the honesty mechanism — a draft with zero markers from sparse notes deserves more suspicion, not less.
Route through the technical review gate. The reviewer is a technician who did not resolve the original ticket. They must: reproduce or desk-check every Resolution step, resolve every [VERIFY], confirm the Environment block matches reality, and check nothing identifying survived. Review verdict is recorded on the article — pass, fix-and-pass, or reject.
Publish with a review date. Every article gets an owner and a review-by date (six months is a sane default). Unreviewed-past-date articles get flagged by the KB health audit (see pb-16).
Track the factory's numbers. Weekly: drafts generated, passed review first time, rejected, and — the one that matters — article link rate on new tickets. A factory whose articles never get linked is producing shelf-ware; revisit candidate selection.
Ticket work notes routinely contain usernames, one-time passwords and customer data — the strip-identifiers rule in the prompt is a first pass, and the reviewer's privacy check is the real control before anything publishes.
AI removes the drafting bottleneck that kept KCS aspirational; the independent technical review gate is what keeps the resulting KB an asset instead of a liability with good formatting.