Knowledge base articles

What a knowledge base article is

A knowledge base article is a short page that solves one specific customer problem from beginning to end. One problem, one page, written so somebody stuck at ten at night can fix it without waiting for a reply. It states what the article covers, gives the steps, shows what success looks like, and says what to do if it did not work.

It is not help centre content, which is the job above this one: deciding what categories exist, what order they sit in, and how somebody finds the right article at all. And it is not a user guide, which is one document read front to back by a person learning the whole product. A knowledge base article is entered halfway through, by somebody who is already annoyed, and it has to work on its own with no context.

The two jobs it does

The first job is the obvious one. Every article that answers a common question well removes a run of tickets, and support time is expensive whether it is a support team or the owner answering at weekends. Ten good articles covering the ten questions you answer most often change how the working week feels.

The second job is the one businesses forget, and it is worth more. Buyers read the knowledge base before they buy. They want to know what goes wrong with your product, how much of it there is, and whether somebody bothered to write it down properly. A thin or abandoned knowledge base tells a careful buyer that support will be thin too. A thorough one, with recent dates on it, quietly answers an objection nobody will ever say out loud to your salesperson.

You do not need this if the questions are pre-sale rather than post-sale. Questions about price, terms, fit and delivery belong on an FAQ page where a prospect will actually see them, and that is cheaper and faster than standing up a knowledge base.

What goes in each one

• A title in the customer's words. What they would type when stuck, not your internal name for the feature. This one decision does more for findability than anything else on the page.
• The answer near the top. A sentence or two confirming this is the right page and saying what the fix is, before any preamble about the product.
• Numbered steps that match the screen. The exact labels a person sees, in the order they meet them, with nothing skipped because it seemed obvious to whoever wrote it.
• The check. How to tell it worked. Missing from most support articles, and the reason people raise a ticket anyway.
• The exits. What to do if it did not work, the two most likely reasons why, and how to reach a human. Naming the failure cases is what makes the article trustworthy.

What you get

The articles. Written one problem at a time, in editable documents or entered directly into your support platform, each with a title, a short summary and the steps. Typically three hundred to six hundred words each.

A template and a short style sheet. The shape every future article follows, with the terms you use for your own features fixed in a list, so the next person to write one produces something that matches. This is what stops a knowledge base becoming twelve voices and four names for the same button.

The queue. A ranked list of the remaining articles worth writing, taken from your ticket history, with the ones that would deflect the most work at the top. You can write them yourself from the template, or send them to me in batches.

A worked example

An illustration, not a client. A small Ontario company sells scheduling software to veterinary clinics. Two staff handle support, and the same handful of problems account for most of the inbox: recurring appointments behaving oddly after a holiday, reminder messages not sending, and staff being unable to see each other's calendars.

I read six months of tickets and group them into twenty-four distinct problems, then write the first twelve. The recurring-appointment article is rewritten three times, because the original explanation assumed the reader had set the rule up themselves, and in a clinic the person who set it up has usually left. Each article names the screen exactly, says how to confirm the fix, and ends with the two reasons it might not have worked. Support hears less from existing clinics on those twelve subjects. The clearer effect is on the sales side: a practice manager comparing two systems reads through the knowledge base on a Sunday and mentions in the first call that it looked like a company that answers its phone. The remaining twelve articles get written by the support staff themselves, from the template.

How it runs

1. A half-hour call. What you sell, who answers support now, and where the articles will live. No charge.
2. A fixed price in writing. A batch size agreed up front, usually ten or twenty articles.
3. Access. Six months of ticket history, a login to the product, and half an hour with whoever answers support most often. That conversation is worth more than the documentation.
4. The list and the template. Five working days. The problems grouped, ranked and named, with one sample article for you to approve before the rest are written.
5. Writing. Ten to fifteen working days for a batch of ten, delivered in twos and threes so corrections carry forward.
6. Delivery. The articles in your platform or as files, the template, the style sheet and the queue.

Three to four weeks for a first batch is typical. Later batches are quicker because the template and the vocabulary already exist.

What it costs

Knowledge base articles are not one of the published bands on the pricing page, so each batch is quoted as a fixed price in CAD after the half-hour call. Batch size is the main driver, and the price per article falls as the batch grows, because the ticket reading and the template are done once. The number is fixed in writing before anything starts.

What happens next

Three things usually follow a first batch. The centre itself gets organised around what customers are trying to do, which matters once there are more than about thirty articles. The same material is reshaped into onboarding material for new staff, since they need the same answers. And the procedures behind the fixes get written down as standard operating procedures so support answers consistently. None of that is assumed. A batch of articles is a complete piece of work and it starts deflecting tickets the day it goes live.