A KCS argument for writing a KB article early

My fellow support engineers, I offer for your consideration a scenario which my team commonly encounters.?

A customer submits a new issue, for which there is no KB article.?The support engineer asks for screenshots, logs, and more details to better understand the problem and identify the resolution.?When the engineer tries to reproduce the issue, quite often it isn’t reproducible on a test environment.?If these initial details are not sufficient, the conversation between customer and engineer will continue throughout the ticket lifespan.?

Eventually, the engineer asks for R&D assistance.?R&D will ask for more information.?Customer later provides this data with the engineer’s assistance.

Finally, R&D provides a hotfix, suggests a configuration change, or insight into whether the product is behaving as expected.?Customer verifies, and case is closed.?The engineer is now ready to write a KB article capturing the issue description, symptoms, and resolution, and does so.?Hopefully, this article will help other engineers and customers in the future, if not for the exact same issue.?The article may provide a starting point and perhaps even a resolution (Yes!).?The engineer has written a perfectly adequate article and has done so while also simultaneously investigating other critical and urgent issues.?But …

Between the time a ticket is raised and closed, a lot has happened over weeks or months.?A lot of work went in from multiple people to closing the ticket, the customer, the support engineer or engineers, developers in R&D, to name but a few.?There are many interlacing details in the ticket, from a generic issue description from a customer, to the hundreds of lines the engineer scans through in a log file to find a stacktrace, to the concise analysis of a developer, and other nuances which must be woven together to understand later why a customer encountered an issue and the steps to resolve it.?Also, the engineer is managing a constantly changing list of complex problems encapsulated in multiple tickets, in the middle of a busy daily routine.?Spending a lot of time ‘excavating’ the details of closed case, for a customer who is no longer held back by this issue, is typically not an engineer’s priority.?Nor should it be, if there are other customers who need help for an issue now.

Writing a KB article after a case is closed is tough.?Too much time has passed.?Some of the contextual details of the case are clear and available, but others are not.?The customer is probably not going to respond to questions about their environment or implementation at this point, they are justifiably concerned with other matters.?The engineer can capture some of the details in the article from memory and notes, but not all of them, and possibly not the most important ones.?Why was the issue seen on one environment but not another, or this customer but not others??

So whenever possible it’s helpful to start the KB article sooner in the ticket lifecycle.?Perhaps as soon as the engineer starts investigating the issue and has a partial view of what the issue is, the symptoms, and has checked that there is no existing KB article which discusses a similar issue.?A draft article can be saved against the case with no resolution, and the article incrementally refined with more details as more information about the issue is captured.??Some of these details are red herrings and can be removed when the issue is later understood.?But it is easier to remove details than trying to add them later.?Yes, there will always be ‘leakage’, and when the engineer needs to make a choice between updating a KB article or joining a customer call, updating the article cannot be the right choice.?But as there is time and opportunity later, the engineer can and should update the article, before the resolution is identified and as the investigation progresses.?The best and most authoritative articles evolve in this manner, incrementally, and with multiple minor edits.?Later, as more cases are linked to the article, the article is enriched by contributions from multiple authors.

The scenario where a KB article is written *after* a case is closed is a common one for my product team.?It’s also a common one for myself lately, although I am a KCS (Knowledge-Centered Service) coach and know that best practice is to start an article sooner.?There are escalations I am working through, imminent customer launch dates, frequent customer calls, issues which are frustratingly not easy to reproduce, the usual list of plausible reasons why I don’t .?On some days, it just seems a better use of my time to work on active issues, and not to be distracted by updating an article which has no immediate value for an issue which has no resolution yet.

And yet… I know that if an article is not thorough, its value is limited and has not fulfilled it’s potential.?A customer or support colleague in the future is not going to be able to find my article if it does not contain the stacktrace which identifies the issue when they search for it.?When there is a GUI related aspect to the issue, a screenshot is going to help someone understand whether my article is relevant or not. ?If I know there are articles with similar symptoms but different resolutions, I need to link to them in my article.?The time I spend refining the article is not wasted, it is valuable, although the value is primarily for my customers and my team rather than myself.?But I use the KB extensively when working a case, and the total time I save finding an article written by a colleague or myself from past cases more than justifies the time needed to write a new article or update an existing one.

Within my company support engineers work on different products, and I am only familiar with the products that I support.?But although we work on different kinds of products and the scenario that I’ve described may not be a precise fit for other teams, I am reasonably confident that there is some overlap.?KCS is a service delivery method that is used by a multitude of companies across the world, and its adoption is only increasing.?It’s been working for my team so far, and it will continue to help us avoid reinventing the wheel with customer issues.?But it does need all of us to have collective ownership of the KB, and expand and maintain it as we go through our daily routines.

Reference(s)

Knowledge-Centered Service (KCS) v6