When to use
Use this after an issue is resolved and likely to recur, or when several customers hit the same thing. Capture the fix once so customers self-serve and agents stop re-solving it.
Not for: one-off issues unlikely to repeat, answering a single live ticket (cs-draft-response), or internal runbooks. If you cannot yet confirm the fix works, research it first (cs-research).
Method
- Title it as the problem the reader searches for, in their words — "Export fails with 'file too large'", not internal jargon. Decision point: if you would not type this phrase into search, rewrite it.
- Add a one-line summary and an "applies to" note (plan, platform, version) so readers self-qualify fast.
- List symptoms exactly as customers experience them — error text, screenshots, behavior — so they confirm they are in the right place.
- Give the resolution as numbered, testable steps: one action per step, expected result after key steps, and any prerequisites or permissions.
- Add an "if that didn't work" branch, and where useful the root cause in plain language so readers understand rather than blindly paste.
- Decision point: before publishing, strip every internal-only detail (ticket IDs, engineer names, unshipped fixes) into a separate internal-notes block.
Example
Title: "Export fails with 'file too large'"
Applies to: All plans · Web · v3.0+
Symptoms: Export button spins, then shows "file too large (>500MB)".
Resolution: 1) Open Export → Options. 2) Set format to CSV (not XLSX). 3) Under Range, split into date chunks under 500MB. 4) Click Export — you'll get a download link per chunk.
If that didn't work: contact support with your account ID.
(Internal: root cause = XLSX serializer memory ceiling, fix tracked in ENG-2214.)
Pitfalls
- Titling with internal jargon — it never surfaces in customer search.
- Multi-action steps — split "configure and export" into separate, testable steps.
- Leaking internal detail (ticket IDs, engineer names) into the published body.
- No "if that didn't work" path — readers who fail step 3 have nowhere to go.
Output format
Title: <search-friendly>
Summary: <one line>
Applies to: <plan / platform / version>
Symptoms:
- <as customer sees it>
Resolution:
1. <one action> → expected: <result>
If that didn't work / root cause: <plain language + contact>
Related articles: <links>
---
Internal notes (do not publish): <ticket IDs, eng, caveats>
1---2name: cs-kb-article3description: Turn a resolved support issue into a search-friendly, self-service knowledge-base article that deflects future tickets — with internal notes kept separate.4---56## When to use78Use this after an issue is resolved and likely to recur, or when several customers hit the same thing. Capture the fix once so customers self-serve and agents stop re-solving it.910**Not for:** one-off issues unlikely to repeat, answering a single live ticket (cs-draft-response), or internal runbooks. If you cannot yet confirm the fix works, research it first (cs-research).1112## Method13141. Title it as the problem the reader searches for, in their words — "Export fails with 'file too large'", not internal jargon. **Decision point:** if you would not type this phrase into search, rewrite it.152. Add a one-line summary and an "applies to" note (plan, platform, version) so readers self-qualify fast.163. List symptoms exactly as customers experience them — error text, screenshots, behavior — so they confirm they are in the right place.174. Give the resolution as numbered, testable steps: one action per step, expected result after key steps, and any prerequisites or permissions.185. Add an "if that didn't work" branch, and where useful the root cause in plain language so readers understand rather than blindly paste.196. **Decision point:** before publishing, strip every internal-only detail (ticket IDs, engineer names, unshipped fixes) into a separate internal-notes block.2021## Example2223> **Title:** "Export fails with 'file too large'"24> **Applies to:** All plans · Web · v3.0+25> **Symptoms:** Export button spins, then shows "file too large (>500MB)".26> **Resolution:** 1) Open Export → Options. 2) Set format to CSV (not XLSX). 3) Under Range, split into date chunks under 500MB. 4) Click Export — you'll get a download link per chunk.27> **If that didn't work:** contact support with your account ID.28> *(Internal: root cause = XLSX serializer memory ceiling, fix tracked in ENG-2214.)*2930## Pitfalls3132- Titling with internal jargon — it never surfaces in customer search.33- Multi-action steps — split "configure and export" into separate, testable steps.34- Leaking internal detail (ticket IDs, engineer names) into the published body.35- No "if that didn't work" path — readers who fail step 3 have nowhere to go.3637## Output format3839```40Title: <search-friendly>41Summary: <one line>42Applies to: <plan / platform / version>43Symptoms:44 - <as customer sees it>45Resolution:46 1. <one action> → expected: <result>47If that didn't work / root cause: <plain language + contact>48Related articles: <links>49---50Internal notes (do not publish): <ticket IDs, eng, caveats>51```
Matrixx0070