A knowledge base that reduces tickets

Somebody decides the team needs a knowledge base. Four people spend an afternoon each writing articles about the things they happen to know. Six months later the search returns nothing useful, two of the articles are wrong, and everyone asks in chat instead.

The failure is in the selection step, not the writing. The articles were chosen by what the authors found interesting or easy to describe, which has almost no overlap with what people actually ask.

The correct input is the ticket queue. Atlassian's knowledge management guidance says it plainly: look at your ticket metrics to find the issues that consume the most time or occur most frequently, and review escalations to identify the complex problems only certain people can solve, because those escalations represent expertise that needs to be shared.

That gives you two different lists. High-frequency low-effort questions are candidates for deflection, meaning the person never needs to ask. High-effort escalations are candidates for capability transfer, meaning a second person can now handle it. They are both worth writing and they are not the same article, and conflating them produces a document that is too long for the first audience and too shallow for the second.

Take the last quarter of requests and group them by the question actually being asked, not by the client or the label on the ticket. Count the groups. Estimate the handling time for one instance, honestly, including the context switch.

Suppose a group has 14 instances in a quarter and each costs 20 minutes end to end. That is roughly 4.7 hours a quarter, or nineteen hours a year. An article that answers it properly might take 90 minutes to write and 30 minutes a year to keep current. Even if it deflects only half the instances, it returns nine hours against two, in the first year.

Now run the same arithmetic on a group with three instances a quarter at 10 minutes each. That is two hours a year. The article costs 90 minutes to write and will be out of date before it earns anything. Do not write it. This is the decision that separates a knowledge base from a wiki, and it is the one that never gets made.

Sort your groups by total annual minutes and draw a line after the top six or so. Those six are the entire project. You can write them in a week and you will know within a quarter whether they worked.

Use your own numbers throughout. The counts above are worked examples of the method, not benchmarks, and any figure you see quoted as a typical deflection rate is describing somebody else's queue.

The last row is where a lot of internal documentation goes to die. Restating a vendor's current behaviour creates an artefact that is wrong the moment they ship, and wrong internal documentation is more expensive than none, because people act on it.

The procedure row is a different artefact entirely and deserves its own treatment, which is why executable procedures with preconditions and stop conditions belong in runbooks for the tasks you do every month rather than in a general article.

Splitting client-facing from internal matters more than it seems. Atlassian describes the two directions explicitly: internal knowledge helps agents resolve tickets faster with verified solutions, while external knowledge published through a self-service portal gives end users direct access to answers. An article written for both audiences at once usually serves neither, because the internal version needs the caveats and the client version needs them removed.

Page views are not deflection. A view might mean somebody found the answer, or it might mean they read it, did not understand it, and then raised a ticket anyway.

Three measures are honest and cheap. First, the count of tickets in the target group, before and after, over equal periods. That is the number that matters and it is the only one that answers the actual question. Second, searches that return nothing, which Atlassian names directly: analytics reveal which articles get the most use, which searches return no results, and which content successfully deflects tickets. A recurring empty search is a commissioned article. Third, how often an agent links the article while answering, which measures capability transfer even when deflection is zero.

Be careful with the before-and-after comparison. If ticket volume in a group falls because the client changed agency contact or paused their spend, the article gets credit it did not earn. Look at the group as a share of total volume as well as in absolute terms, and be willing to say the article did nothing.

Where the product does the deflecting, it happens at the point of request. Jira Service Management's knowledge base is built so customers can help themselves by searching articles in the help centre and so that agents can solve requests faster by sharing articles while they work. That is the mechanism to copy even without the tool: surface the article in the reply, every time, so the client learns the resource exists.

None of this is time saved until you can point at the hours. The discipline for that claim is in measuring time saved honestly, and it applies to knowledge work exactly as it does to automation.

Documented knowledge has one persistent weakness. Atlassian puts it in a single line: explicit knowledge is easy to store and retrieve, and the challenge is ensuring it is reviewed and updated.

Do not solve that with a review calendar nobody honours. Solve it with a trigger: the article gets checked whenever it is used to answer something, and the person who used it fixes what was wrong. Add a last-verified date and the name of whoever verified it, so a reader can judge for themselves.

Then apply the harder test. A recurring question is evidence of a defect somewhere, and the article is a workaround. If clients keep asking why two platforms disagree, the article helps, but the underlying confusion may be a measurement configuration nobody has corrected. If the team keeps asking which query produces the monthly figure, the real problem is that the definition is not written into the model.

Jira Service Management draws that line as a cause and effect relationship: problems are the cause, incidents are the effect, and fixing an incident means to temporarily restore an impacted service without addressing the underlying cause. A widely read article is a documented workaround, and a documented workaround is a standing invitation to ask what would remove the need for it.

That is the distinction between managing symptoms and removing causes, and it is the whole subject of problem management versus firefighting. A knowledge base is where you find your problem candidates, because the articles with the highest traffic are pointing at the parts of the system that are hardest to understand.

The commercial version of the same idea is a defined menu of requests, so that a client asking for something recognises the shape of it before they ask, which is what a service request catalogue for an agency sets up, and which belongs alongside the assumptions and exclusions produced during statement of work scoping. Between a catalogue that says what you do and six articles that answer what people actually ask, most of the repeated conversation in a small firm disappears.

Start with one article, for the question you answered most recently for the third time. Write it in the reply itself, then paste that reply into the knowledge base. That is the whole first iteration.