Knowledge base software: evaluate search, answers and maintenance

Start with the questions customers really ask

Collect a small set of recurring questions from authorised support material, then remove personal details before using them in a vendor evaluation. Keep the customer’s wording. Someone may ask where their bill went rather than search for the name of an internal billing feature. A library that only works for product experts will leave that person behind.

Choose questions that need different kinds of answer: a short explanation, a step-by-step task, a permission problem and a case requiring a person. Write down what a useful result would contain. This gives the team a shared standard before anyone becomes attached to a particular search interface.

Test the whole answer journey

For a fictional appointment-software company, one useful question is how to change a booking. Another is why a colleague cannot see a calendar. A third is how to recover a booking made under the wrong account. These should not all lead to the same broad introduction.

Ask a colleague who did not write the content to search, select an answer and explain the next action. Record unclear terms, missing conditions and dead ends. The evaluation is about whether the answer works for its intended reader; a page appearing first in results does not establish that its instructions are complete.

Treat search metrics as clues

Zendesk’s search analytics documentation describes queries, results, clicks and related ticket activity. Those are useful signals for investigation. A frequently repeated query with no results deserves a closer look at terminology and coverage.

Do not turn one metric into a universal judgement. A search with no click might reflect an unhelpful result, but an answer displayed directly in the search experience can also change clicking behaviour. Zendesk’s search overview describes generated-answer experiences. Examine the actual result and reader journey before calling a number a success or failure.

Separate viewing rights from editing rights

An internal troubleshooting article may be appropriate for trained staff but unsuitable for a public help centre. A colleague who can read it may still have no authority to change or publish it. Zendesk’s knowledge permissions guidance separates those scopes.

Evaluate the actual audiences and editorial roles you need. Use a synthetic internal article and a public article, then inspect what each intended role can find and do. If the knowledge base feeds an AI assistant or another channel, check that channel’s content availability as a separate configuration rather than assuming every permission transfers unchanged.

Give every important answer a maintenance owner

A help centre accumulates outdated screenshots, old plan names and instructions for features that moved. Choose an owner for each important topic and a way for support staff to report a correction. Keep the applicability and review context with the article so another person can decide whether a change is necessary.

For the appointment example, a calendar-permission change should trigger review of the access article, any linked checklist and the message agents send customers. This is a small content dependency, not just an editing task. Ask how the selected software handles drafts, review, publishing and replacement of material that is no longer appropriate.

Choose an operating routine as well as a platform

Budget the subscribed package, contributors, languages, required search features, migration and ongoing content work. The people maintaining answers can be a more important constraint than the initial theme setup. Start with a manageable set of valuable questions and improve it from observed use.

Compare the Zendesk, Intercom and Document360 profiles. Keep the evaluation notes with the help desk RFP if self-service is part of a wider purchase. The strongest evidence is a reader finding the right answer and a team able to keep that answer current.

Frequently asked questions