Building a knowledge base

Why most knowledge bases die

Because they are written in a separate place, in a separate session, by someone who has already answered the question. By the time the article exists, the person who needed it has moved on – and nobody looks there first, because it has never yet had the answer.

Write it while answering, not afterwards

The only version of this that survives is the one where writing the article and answering the ticket are the same act. You answer a question well, and that answer becomes the article – no separate session, no backlog of documentation.

What belongs in it

• Answers you have given more than twice.
• Procedures with steps somebody will get wrong from memory.
• The things only one person knows – before that person is on holiday.

What does not

• Anything that changes monthly. It will be wrong, and a wrong article is worse than none.
• Long documents. If it needs a table of contents, it needs splitting.
• Things nobody has actually asked. Write in response to reality, not in anticipation of it.

Getting it found

An article nobody finds is an article nobody wrote. Two things help more than any amount of tagging: full-text search that actually works, and a system that offers the matching article inside the ticket while the reply is being written. The second one is what turns a knowledge base from an archive into a tool.

Keeping it honest

Put a date on every article and review anything older than a year. Delete rather than update when something is no longer true – an empty knowledge base is embarrassing, a wrong one is expensive.

What good looks like after six months

Thirty to fifty articles, all of them written because somebody asked. New colleagues answering common questions in their first week. And at least one occasion where a customer got an answer in two minutes that used to take a day.