It was the middle of the week, a Wednesday. I had started this technical support job two and a half weeks prior, and today was the day. I had learned the basics of the products I would support and I had shadowed on other engineers' calls. I knew how to work the ticket management system. I knew where to look for answers I did not know. I knew that my teammates would help me if I asked them. I answered my first support call at that company, and I had no clue what the answer was to the problem.
Even though I had no idea what the answer to the problem was, I wasn't worried. I pulled up the wiki and searched. The first search did not give me the answer, so I took a breath and thought about my wording. I tweaked the search. About five entries down the search results was the answer.
I skimmed over the article and became certain that this was what the customer needed. I briefly outlined the necessary steps to the customer, emailed them the article, and asked what else I could do for them.
And then it was done. My first call at the company was done. All the first-call anxiety and excitement left me. I took some deep breaths. I probably did a little happy dance, but I don't remember for sure. Then I got ready for my next call.
A well-maintained wiki is the technical support engineer's best friend.
- New hires can get answers to problems quickly and learn quickly when the common problems are searchable.
- Engineers are more likely to be consistent with each other when answering questions when answers are documented in a wiki
- People working second and third shift can sift through group knowledge before needing to wake someone up from their sleep.
- Engineers can showcase their knowledge by writing articles.
- Customers are happy when the Time To Resolution is fast.
- Many customers like to search through a Knowledge Base (KB) to find the answers they need without engaging technical support. A lot of people like self-service.
What makes a good Knowledge Base?
A good KB is easy to search. To do this:
- Categorize KB articles logically by technology, topic, or issue type.
- Utilize a clear and consistent structure for each article.
A good KB has:
- answers for all the common issues customers will face, and
- answers for uncommon issues, and
- a strategy established to ensure that tricky and new problems are well documented, and
- a strategy and plan to remove out-of-date articles, and
- a regular review to determine if specific articles need to be written, and
- a version control system in place to show changes to articles over time.
What makes a good article?
- Title: Briefly describe the issue or solution.
- Summary: Provide a concise overview of the article content.
- Symptoms: List common symptoms or indicators of the issue.
- Troubleshooting Steps: Outline a step-by-step guide to resolve the problem.
- Resolution/Workaround: Provide the solution or recommended workaround.
- Additional Resources: Include links to relevant articles or documentation.
