To write a KB article:

1. Pick article type: Troubleshooting / How-To / FAQ / Known Issue / Getting Started
2. Pick audience: End User / IT Staff / Developer / SysAdmin
3. Draft sections in order: Title → Symptoms → Affected Versions → Prerequisites → Resolution (or Workaround+Status if Known Issue) → Closing
4. Flag any version-specific paths, internal names, or unverified patch dependencies with <!-- VERIFY: ... -->
5. Run the checklist before publishing

Example header to start every draft:

Article Type: Troubleshooting
Audience: End User

Progress:

• Step 1: Identify article type (determines skeleton)
• Step 2: Identify audience (determines vocabulary/detail level)
• Step 3: Write title (≤70 chars, searchable, no jargon)
• Step 4: Write symptoms (second-person, observable only)
• Step 5: Write affected versions/environments (explicit or flagged as unverified)
• Step 6: Write prerequisites (access, tools, pre-tasks)
• Step 7: Write resolution steps (numbered, audience-matched detail)
• Step 8: If Known Issue — replace Resolution with Workaround + Status
• Step 9: Add closing section (escalation, related articles, contact)
• Step 10: Insert VERIFY flags on anything version/environment-specific
• Run Best-Practice Checklist

Step 1 — Article Type Selection

Rule: if no fix exists yet, it's Known Issue, not Troubleshooting — even if symptoms look identical.

Step 2 — Audience Selection

Record this as Audience: X at the top of the draft — it's the reviewer's reference point.

Step 3 — Title

• Plain language, no codenames/internal IDs
• Include primary symptom + app name if relevant
• ≤70 characters

Example: "Cisco AnyConnect VPN fails to connect after Windows update – 'Tunnel not found' error"

Step 4 — Symptoms

• Second person: "You may see…"
• Exact on-screen text/UI elements/observable behavior only — no root-cause analysis here

You may notice:
- Symptom 1 (exact error wording)
- Symptom 2 (observable behavior)

Step 5 — Affected Versions/Environments

• List confirmed version numbers/OS builds/dates
• If unknown: state explicitly — "Tested on version X.Y; verify against your version"
• Include environmental qualifiers ("domain-joined only", "requires corporate VPN")

Step 6 — Prerequisites

• Bullet list, each item starts with a capital letter
• Cover: access level, required tools, pre-tasks

Step 7 — Resolution Steps

• Numbered list, one actionable sentence per step, <30 words
• Split complex actions into sub-steps (a., b., c.)
• End-User audience → exact menu paths ("Start → Settings → Network & Internet")
• Technical audiences → command syntax, config paths, API calls
• Add verification cues where useful ("You will see a 'Connected' status")

Step 8 — Known-Issue Branch

If article type is Known Issue:

• Remove the Resolution section entirely
• Add Workaround subsection (temporary mitigation steps)
• Add Status line: "No confirmed fix yet – under investigation by the product team (Ticket #12345)"
• Optionally link the tracking ticket (internal link only for internal audiences)

Step 9 — Closing Section

• "Still having issues?" — contact method (phone/email/portal)
• Related articles — up to 3 relevant KB links
• Escalation path (internal audiences only) — next support tier, required info, SLA

Step 10 — Verification Flags

Insert <!-- VERIFY: ... --> wherever:

• Version-specific file/registry paths appear
• Internal system/hostnames/proprietary tools appear
• A step depends on a recent patch not universally deployed

These must be reviewed by a senior writer/SME before publishing.

Example 1 — Troubleshooting, End User Input: VPN disconnects after Windows update, error "Tunnel not found" Output:

Article Type: Troubleshooting
Audience: End User

# Cisco AnyConnect VPN fails to connect after Windows update – "Tunnel not found" error