The knowledge base is help content for your customers. Articles they read instead of contacting you.
This help centre is built with it, which is either reassuring or a warning depending on how this article goes.
What you get
Two views, and that is deliberately all.
Articles. Writing, editing and publishing them.
Categories. How they group.
If you have read about architect, strategy, calibration or planner tabs elsewhere, those are NearSync's own content operations tools and are not part of a tenant's knowledge base. You will not see them, and nothing is missing.
Publishing takes two switches
The one thing most likely to waste an afternoon.
An article is public only when it is published and customer-facing, and its category is public and not archived. All of those, together.
An article that is published but not customer-facing stays private. This is the usual cause of "I published it and it is not there", and nothing warns you, because both states are legitimate: internal-only articles are a real use.
Check both before concluding something is broken.
Categories are the navigation
For readers, the category structure is the whole of how they find anything. It matters more than it does on a blog.
Group by the job, not by your product structure. Somebody with a broken invoice looks for billing, not for the name of the module that owns invoices.
Order deliberately. An article's position within its category decides what somebody meets first, and the first article should be the overview rather than whatever sorts alphabetically.
Do not create a category for two articles. Fold them into a bigger one until there is enough to warrant the shelf.
Who writes them
Whoever answers the question today. Support writes the best help content in most organisations, because they know the exact wording people use and the exact place they get stuck.
What to write
Start from your support queue. The five most common questions are the first five articles, and they will do more work than the next fifty.
One question per article. An article covering three things is found by nobody looking for any of them.
Title it as the question, or as the task. "Changing your billing address" is found. "Account administration" is not.
How long an article should be
Long enough to actually answer.
The instinct is to keep help articles short, and it produces content that is technically accurate and practically useless: the reader gets the four obvious steps and none of the thing that was actually confusing.
Write the version that ends the conversation. Include the edge case, the thing that goes wrong, and what to do when it does. A reader who finishes an article and still has to write to you cost you both the reading time and the ticket.
Publishing checklist
Four things, thirty seconds, before anything goes live.
Both switches on, published and customer-facing.
The category is right, and public.
The title reads as the question somebody would type.
Something links to it. An article no other article points at is one only search will ever find.
Keeping it true
Help content rots silently, because nothing breaks when the product changes.
Fix the article the same day the thing changes. Not in a review cycle. A customer following out-of-date instructions is worse off than one following none.
Delete rather than archive anything describing something that no longer exists. Two versions of the truth in one knowledge base is worse than a gap.
Read the ones you never touch. The article written first is usually the most read and the least maintained.
Categories, in practice
Four or five, named for the job.
Watch what people search for, if your site gives you that, and rename categories to match. The gap between what a business calls something and what customers call it is usually large and always costs you.
Put the overview first in every category. Position decides what somebody meets, and meeting the fourth article cold explains nothing.
Why it is worth more than a blog
People arrive at help content with intent. They have a problem, they are your customer or nearly, and the article either keeps them or loses them.
Blog readers are browsing. Help readers are stuck.
Every article is a support conversation that does not happen, and unlike a blog post it keeps working indefinitely. An article answering a common question written today is still deflecting tickets in three years.
Structure inside an article
Help articles are scanned before they are read, and the scan decides whether the read happens.
Headings that say what the section covers, so somebody can jump. "If the payment fails" is a heading somebody finds. "Additional information" is not.
The answer near the top. Background afterwards, if at all. The reader who already understands the context should be able to stop after the first paragraph.
Steps as steps. Anything sequential should look sequential.
One thing in bold per section at most. A page where everything is emphasised has no emphasis.
Measuring whether it works
You will not get article-level analytics from this surface, so use the proxy that actually matters.
Count the question, not the article. If "how do I change my billing address" arrived twelve times a month before you wrote the article and four times after, the article works. That number comes from your support queue, and it is a better measure than page views because it is the outcome rather than the activity.
Write the five most-asked first, then re-measure. If the count does not move, the article is not answering the real question, which usually means the real question was one step earlier.
Two habits
Link between articles. Somebody with one question usually has the next one, and the article that answers it should be one click away rather than a search away.
Say what something is not. A surprising amount of confusion is somebody using the wrong tool for the job, and one sentence pointing them elsewhere resolves it faster than a perfect explanation of the wrong thing.
Did this answer your question?
No, ask a person