Most support articles fail for one reason: they’re written for the person who wrote them, not the person who needs them.
I see it in almost every knowledge base I walk into. Long introductions. Screenshots of every menu. Perfect grammar describing a problem in words no customer has ever typed. And a search bar that returns nothing useful.
Knowledge-Centered Success (KCS) flips the question. It doesn’t ask “Is this article perfect?” It asks two things:
- Can the next person find it?
- Can they use it to solve their problem?
That’s the whole bar. Findable and usable. Everything below is how you get there.
1. Write it in the customer’s words
Your customer doesn’t say “SSO token validation failure.” They say “I can’t log in and it keeps sending me back to the start page.”
Guess which one they type into the search bar.
KCS calls this capturing the requester’s context. You record the problem the way the person experienced it: their symptoms, their error message copied exactly, their phrasing. Not your diagnosis. Not your internal product name.
This is the single biggest driver of findability. If the article doesn’t contain the words people search with, it doesn’t exist. However good it is.
Try this: open your last ten articles. Count how many titles a customer would actually type. Be honest.
2. Use a simple, consistent structure
A KCS article isn’t an essay. It’s a small, predictable shape:
The four sections of a KCS article: Issue, Environment, Resolution and Cause (optional), with what goes in each.
Issue: What the person sees or wants, in their words. Example: “Outlook keeps asking for my password after the update”
Environment: What’s in play: product, version, OS, setup. Example: Outlook for Windows, Microsoft 365, version 2409
Resolution: The steps that fix it or answer it. Example: 1. Close Outlook. 2. Clear cached credentials. 3. Restart and sign in.
Cause: Why it happened, if known. Example: Stale credentials stored before the update
Why does this matter? Because when every article looks the same, people stop reading and start scanning. They jump straight to the Resolution. They check the Environment to see if it matches theirs. Done.
Keep each section tight. Short sentences. Numbered steps. One action per step. If a step needs a paragraph to explain, it’s probably two steps.
And Cause is optional. Don’t hold an article back because you don’t know why yet. The fix is what people need today.
3. Write a title people will actually click
If you followed the order I suggested, then now is the time to think about the title (and not the first thing to write when you start an article) and it will come a lot easier to you once you have written the content of your article. The title does most of the work when it comes to findability. In a list of search results, it’s often the only thing anyone reads before deciding to click or move on.
A good KCS title is usually just the Issue, in the customer’s words. Not a category. Not a summary of the fix. The problem, as the person would describe it.
- Lead with the symptom, not the solution. People search for what’s wrong, not for the answer they don’t know yet.
- Be specific. Name the product, the action and what goes wrong. “Login issue” matches everything and helps no one.
- Use their words, not yours. Skip internal codes, team names and acronyms customers never see.
- Include the exact error message when there is one. It’s the most searched text there is.
- Put the important words first. Search results and mobile screens cut titles short.
A few examples:
Instead of: Password problem Try: Outlook keeps asking for my password after the update
Instead of: VPN troubleshooting guide Try: VPN disconnects every few minutes when working from home
Instead of: How to fix printing Try: “Printer offline” error when printing from Teams
Instead of: SSO token validation failure Try: Can’t log in, keeps sending me back to the start page
Quick test: read your title out loud. If it sounds like something a frustrated person would say to a colleague, you’re on the right track.
4. Aim for sufficient, not complete
This is the one that makes perfectionists uncomfortable.
In KCS, an article only has to be good enough to help the next person who finds it. Not polished. Not exhaustive. Sufficient to solve.
The cost of waiting for perfect is huge. While one article sits in a review queue for three weeks, ten other agents solve the same issue from scratch. Ten customers wait longer than they needed to.
A rough, accurate article published today beats a beautiful one published next month. Every time.
That doesn’t mean anything goes. Your organization still needs a content standard: a short, agreed definition of what “good enough” looks like. Title format, required fields, tone, what never goes in an article. Keep it to a page or two. If nobody reads it, it isn’t a standard.
5. Capture it while you solve it, not after
Here’s the dirty secret of most knowledge bases: articles get written at the end of the day, from memory, by someone who’s tired.
The details are gone. The customer’s exact error message is gone. What you tried that didn’t work is gone.
KCS asks you to capture as you go. Start the article (or update an existing one) while you’re working the issue. Paste in the customer’s words. Add steps as you test them. By the time the ticket is closed, the article is mostly written.
It also means searching first. Before you start from scratch, search the knowledge base using the customer’s words. If something’s already there, reuse it. If it’s close, improve it. Only create new when nothing fits.
No extra project. No “documentation week.” Just part of how the work gets done.
6. Let use improve it: reuse is review
A good article isn’t finished when it’s published. That’s when it starts getting better.
In KCS, every time someone uses an article, they review it. Does it still work? Is a step missing? Is the title clear? If they can fix it, they fix it. If they can’t, they flag it for someone who can. Flag it or fix it.
This is why you don’t need a big editorial team signing off on everything up front. The articles people use most get reviewed most. The ones nobody touches don’t need much attention anyway.
It only works with one mindset shift: nobody owns an article. The team owns the knowledge.
When I train people on KCS, I like to use a simple saying: see something, do something.
Think of trash on the office floor. You can step over it, ignore it, and then complain the place is dirty. But then you’re part of the problem. Knowledge works the same way. Spot an outdated step, a confusing title or a missing error message? Fix it or flag it. Don’t walk past it.
7. Where AI fits (and why this matters more now, not less)
Every support leader I talk to is asking the same question: can’t AI just write the articles for us?
Partly, yes. And that’s great news. But only if the foundation is right.
AI as a drafting partner. The ticket already holds the customer’s words, the environment details and the steps the agent tried. AI can turn that conversation into a first draft in Issue / Environment / Resolution / Cause format in seconds. The agent’s job shifts from writing to validating: Is this accurate? Is it in the customer’s words? Would it actually work? That’s capture in the workflow, with a lot less typing.
But notice what AI is drafting into: your structure and your content standard. Without those, you just get faster inconsistency.
AI as an analyst. This is the part people underestimate. When every article follows the same structure and is linked to the tickets it solved, you suddenly have clean, comparable data. AI can spot which issues are rising, which products or versions keep showing up in the Environment, and which Causes point to a fix your product team should make. That’s how support stops just reacting and starts preventing.
Messy, inconsistent articles give AI nothing to work with. Structured ones give it a pattern to find.
AI as the front door. More and more customers will never see your article. They’ll see an answer generated from it, by a chatbot or a self-service assistant. If the article is vague, outdated or written in internal jargon, the AI answer will be too. Just delivered more confidently.
So no, AI doesn’t make good articles less important. It makes them the foundation everything else sits on. And a human still owns the final call on whether the knowledge is right.
A quick checklist before you hit publish
- Did I search first, and reuse or update instead of duplicating?
- Is the title written the way a customer would describe the problem?
- Does the Issue include the exact error message or symptom?
- Is the Environment specific enough for the customer to tell if it applies to them?
- Are the Resolution steps numbered, one action each?
- Could the customer, or a brand-new agent, follow it without help?
- Is it accurate? (Not perfect. Accurate.)
The real test
A good support article isn’t measured by how it reads. It’s measured by what happens next: the customer who fixed it themselves, the new hire who closed a ticket on day three, the escalation that never happened.
My job as a consultant is to make other people the experts. Good articles do the same thing, at scale.
If your team keeps solving the same problems over and over, or your knowledge base is full of articles nobody can find, let’s talk. That’s exactly the problem KCS was built to fix and I can help you implement it and adopt it so it sticks 🙂