5 Reasons Why Support Engineers Don’t Contribute to the Knowledge Base

Continuing our 5 Reasons series, this month we talk about why support engineers are not contributing enough to the knowledge base, or not the type of contribution you’d like them to make.

Here are five reasons why support engineers are unwilling, unable, or unsuccessful with knowledge management–with solutions for each. We’ll start with a basic issue: fear.

1. They have English-essay phobia

Support engineers send emails (and other written communication, like texts) to customers all day, so it’s remarkable to observe how reluctant they are to write a knowledge base article. Somehow, writing a formal document conjures up their middle-school English teachers, who seem to be formidable, even terrifying beings. And, to be fair, many support engineers are not native speakers, so their concerns are especially understandable.

Still, if you trust support engineers to communicate with customers, they can write  articles. Reassure them that their writing skills are sufficient, allow videos alongside articles for those who prefer to talk, and provide AI tools to automatically draft articles that are grammatically correct. Also attend to reason #2, below.

Lesson: Emphasize the value of short, serviceable articles

2. The content standard is too complicated

I see a lot of content standards that are picky, overly detailed, and more appropriate for professional technical writers than for support engineers. In most B2B environments, customers (and internal users) are quite happy with basic formatting. In any case, you can add a layer of AI automation or a human edit to reach the level of polish you think is needed. Don’t ask the support engineers to do fiddly work.

Lesson: Let the support engineers create with few guidelines, focusing on intelligibility rather than formatting

3. They wrote articles that went ignored

Especially if you enforce reviewing each and every article before publication, there can be serious delays in new articles becoming available to other internal users and customers. This is a source of great frustration for prospective authors, and a sure way to extinguish any enthusiasm for knowledge management work.

Set ambitiously fast deadlines for reviews, like one business day–and enforce them.

Lesson: Publish articles swiftly

4. The metrics don’t reward KB contributions

Many support organizations focus productivity goals on closing cases and seem to treat knowledge management tasks as something done out of the goodness of the team members’ heart. It makes no sense! If knowledge management is important, it needs to be rewarded. It’s ok to measure creation and update rates but beware the end-of quarter rush and attending shoddy output. The best approach is to view knowledge management as a quality practice, measured by case and article audits.

I also like capturing impact: a knowledge base article that was reused dozens or hundreds of time saved a lot of work. Give credit to authors who share useful knowledge.

Lesson:  Make sure metrics rewards positive knowledge management work

5. They think they can just search cases

AI searches have become so good that it’s tempting to think that support engineers will ferret out information out of existing case documentation, with no need for knowledge management. That’s partially true, but true only for those lucky individuals who have access to the case data (or bugs data, or other internal repositories).

The good news is that AI tools are really, really good at automating knowledge creation, including obscuring PII data. Even if the support engineers don’t have the KCS discipline of creating knowledge while they solve cases, it’s really easy to create a knowledge base document from a case. Encourage post-case, immediate knowledge creation through the quality audits mentioned early.

Lesson:  Emphasize the benefits of a clean knowledge base for all users

What do you to encourage your support engineers to contribute to knowledge management? Please share in the comments.

(And if you need help, we can help.)