We all hate our knowledgebase tools sometimes. We might like the people we work with at the vendor, and there are those really cool features, but…seriously? I can’t just get a list of all the articles Joe has written? I can’t use bullets without ruining the formatting? I have to hit “publish” three times after I’m finished with the article? It makes you tear your hair out, and you sometimes get the impression vendors have no idea how their products are used in the real world.
As a knowledge program manager, every time you meet with a KCS coach, or sit down with a staff member, you get both barrels about the technology. “Search doesn’t work—why can’t it be like Google?” “It’s too cumbersome to author in the workflow.” “It takes a half hour to create a KB article even after you’ve captured the information in the case.”
It’s easy for consultants, industry pundits, and even program managers to say it shouldn’t matter that much—that many knowledge programs have succeeded with technology that’s no better, or even worse. It may be true, but it’s not very helpful to say to a complaining colleague.
Based on some recent experience with customers, I’d suggest a different approach. Tell your team to hack their knowledgebase.
No, I don’t mean hack in a bad way. I mean hack, like, figure out how to make it their own. Come up with new clever ways of using the system. Devise workarounds. Write a script. Show off, and have some fun! You have smart people in your organization…maybe all they need to use the tool better is permission, and encouragement?
As program managers, we helped implement the tool, and we built the training content, so we come to think of ourselves as the experts. But we’re not, really, at least, not compared with the people who use it every day. Here are some things I’ve seen end-users figure out, all within the last three weeks:
- How to use a “hotkey text” feature to automatically paste a template into a new article (a workaround discovered by two different users in two different systems)
- How to eliminate rich text formatting problems by slightly changing the content standard
- Metadata entry that can be skipped, because no one ever looks at it
- How to generate “reports” that aren’t available in the reporting system by cleverly using an administrative interface
- How to keep a shared stash of article IDs to link for common issues
These MacGyver moves all came about because users were frustrated with the tool, and rather than complaining, they rolled up their sleeves and did something about it. As a program manager, you’re not always in a position to figure this stuff out. But you can prod and encourage would-be hackers, recognize their contributions to the program, and most importantly, make sure that everyone on the whole team knows when a colleague has come up with a better way to do things.
Leave a Reply