Self-service and knowledge

Good self-service is the cheapest support you will ever run and the most neglected. It is also frequently the wrong answer — an article explaining a confusing screen is a bandage on a design problem.

Decide what deserves an article

Before writing, ask whether the contact should exist. If people repeatedly need instructions for one screen, the screen is the defect. Documenting it makes the problem permanent and invisible.

Write articles for things that are genuinely complex, genuinely occasional, or genuinely outside your control. Not for things that are merely badly designed.

What to write, and in what order

Rank by contact volume, not by feature importance. The most-viewed help content is almost never what the team expected — it is billing, access, and the one confusing setting.

Structure each article around the customer's task, in their words, not your feature's name. People search for what they are trying to do.

• Answer first. The steps in the first screen, context afterward. Nobody arrives wanting background.
• One task per article. Combined articles fail search, because the match lands on the wrong half.
• Show the actual interface — real labels, real button names, updated when they change.
• Say what to do when it does not work. The next step, and how to reach a human. Making that hard converts a solvable problem into a complaint about you hiding.

Findability decides everything

An article nobody finds does not exist. Findability comes from titles matching real search language, in-product links at the moment of confusion, and search that tolerates the words customers actually use rather than your internal vocabulary.

Read your help-center search logs, especially the queries returning nothing. That list is your content backlog, ranked by demand, already written for you.

In-product beats the help center

Guidance at the point of confusion deflects far more than a help center does, because it requires no decision to go looking. A well-written empty state, field hint, or error message removes contacts that documentation never would.

Maintenance

Documentation rots silently and confidently. Every article needs an owner and a review date, and anything describing an interface needs checking whenever that interface changes.

Wrong documentation is worse than none: it costs the customer time and then a contact anyway, and it spends trust.

Measuring

Deflection honestly — contacts avoided, not page views. Approximate it by looking at whether contact volume for a topic falls after content ships.

Watch articles with high views and a high subsequent contact rate. Those are articles that are failing to answer, and they look like your best-performing content.

Sources

references/sources.md in this skill lists the outside authorities that settle the questions here — what each one is authoritative for, and what you may do with it. Check them before answering on anything they cover, and cite what you used. Most are free to read and not free to reproduce; the use note on each is binding.

Never

• Write an article for a problem the product should not have. Fix the product and delete the article.
• Publish without an owner and a review date. Stale help is worse than no help.
• Measure a knowledge base by article count.
• Hide the path to a human. Deflection that traps people costs more than the ticket would have.