A few months back I had the opportunity to talk with over thirty Support Engineers, most working for established software companies with mature products.
Surprisingly, many of them told me they frequently find themselves in a situation where they couldn’t trust the documentation. The same documentation is supposed to help them find solutions and resolve tickets faster.
This was an interesting finding, knowing that KCS has been around for more than 20 years.
I believe one of the reasons many teams are not adopting a knowledge-centered service, is because they think it requires a significant investment.
You need to “implement” KCS: purchase expensive tools, hire new people and get consultants to help.
This might be true for very large organizations, but if you are a relatively small or medium-size company you can have a knowledge-centered approach without even realizing it. In this article, I will describe a set of practices that will help Technical Support Teams put knowledge at the center of how they work.
Symptoms of Poor Knowledge Management
Many years ago I was working for a small software startup in Dublin as a developer. The product was very complex and hard to troubleshoot. I was spending an important amount of time explaining the same concepts over and over again.
It was frustrating as I wanted to spend my time building software rather than explaining troubleshooting steps repeatedly.
These are some of the symptoms you could spot when knowledge is not considered a strategic business asset.
- Knowledge is centered in small clusters of experienced developers or senior technical support engineers
- Experienced team members are bombarded with requests and questions. They spend a significant amount of time explaining the same concepts over and over again.
- Team members don’t trust the documentation. They can’t tell if the docs are accurate and up to date. For this reason, they need to keep checking any non-trivial questions they have with their more experienced colleagues.
Think about it this way:
Most of the time an engineer spends understanding a problem by asking other colleagues is waisted unless the produce of the understanding is not written down and shared with the team.
Build a Knowledge Sharing Culture and a Long Term Thinking One
In Support, you’re constantly working on resolving immediate issues for customers. It’s your main task. Ticket by ticket, you go as fast as you can through the queue to see the end of the day.
This makes it very hard to pause, think and do things differently. Especially things whose positive impact builds up slowly over time, like a knowledge base. It requires discipline and tolerance for delayed gratification.
To adopt a knowledge-sharing mindset, a cultural shift needs to happen in your team. A culture that balances long-term thinking with short-term tasks.
Changing how people work is hard, but not impossible. You can employ similar methods to those used to change unwanted behaviors in children.
Explain the why
This is crucial. Make sure the team fully understands why capturing and sharing knowledge as they work is important. If you can, use examples from other teams or companies.
Like with kids, explaining is not something you only do once. You need to keep explaining and repeating yourself for weeks or even months. Build up the argument as you progress and the real impact of having a solid knowledge-sharing practice starts to kick in.
Praise and reward
I think we underestimate the power of in the moment, honest praise. People want to make an impact: on the team, customers, company or world in general. If they think they don’t care, they lie to themselves.
The more you highlight the impact they make on the shared team knowledge, on the customers and the business, the more likely they will continue the right behaviour.
Be a role model
Take every opportunity to show your team how to do the right thing.
Work with them on this, side by side, as your time allows it. Capture and reuse knowledge at every opportunity, rather than asking other teams over and over or trying to re-inventing the wheel.
Capture, structure, reuse, improve
The KCS principles are simple. You don’t need to read books to understand them. The hardest part is figuring out how you put them into practice: adapt and apply KCS into a framework that works for your team.
To adopt KCS you need to implement a continuous loop of capturing, structuring and reusing knowledge while the team is actively supporting customers.
Capture
For every new customer request, search if there is an existing article that could be used as an answer. If there isn’t, create a new article and document the solution provided to the customer. Try to use the language and phrasing used by the customer when describing the problem.
Structure
Don’t let your team start from scratch. Use templates to help them get started with writing documentation on a new topic. This simplifies their workflow and ensures consistency across the entire help centre.
Reuse
Don’t reinvent the wheel for every new customer issue. Always search the knowledge base first and use links or paragraphs within articles to write the response to the customer.
Improve
If the article contains out of date information or doesn’t fully address the customer question, make all the necessary updates. This will keep the content fresh and prevent the “I don’t trust the documentation” problem mentioned at the beginning.
And that’s all it is: capture, structure, reuse and improve. The four steps are very simple. Just that the hardest part is helping your team break the old habits and adopting a new mindset.
The good news is that once you gain some momentum, the benefits of this process become more and more obvious to your team. Remember, the value builds on itself.
Written by Sorin Alupoaie
Sorin Alupoaie is the founder of Swifteq, an experienced software technologist and entrepreneur, he loves shipping products that solve painful customer problems. Sorin strongly believes that any Customer Service interaction represents a huge opportunity for a business to listen and improve how they deliver value to customers.
