Why KCS?

In August 2013, Western Kentucky University (WKU) adopted a new ticketing software solution across the IT division. We went from a system built in-house (held together with duct tape and rubber bands) to an enterprise solution. At the time, we were not fully aware KCS was our missing piece in the service desk, but it quickly became clear when we saw what our new software was capable of.

When the dust settled from migrating platforms we put a target on implementing KCS into our practices in 2014. We wanted to adopt some of the KCS functionality our new toy brought to us, even though all our previous efforts had ended in a lot of frustration. At the time, we did not have a living knowledge base, just lots of different FAQs, system-specific knowledge bases, a Wiki page, notebooks, old ticket notes, and lots of employee knowledge. Rather than do the same things we had always done, our service desk manager discovered the KCS Foundation training through HDI. Failure with KCS was what we were good at, and we knew we needed training before attempting a knowledge base again.

Our service desk manager, two other service desk employees, and I achieved the HDI KCS Foundation certification. I remember the training blowing our minds; at one point, I turned to my colleague and said, “Wow. I fully understand why everything we have ever done was incorrect.” We had gone about everything before backwards and wrong. After feeling equipped with our new knowledge, we sought to implement KCS, though not with the entire IT Division. We all know how IT works; you will never, ever, get full buy-in from every employee. So, we set out to make a knowledge base for our service desk employees. If that proved successful, we would start encouraging and nudging other areas in IT to participate.

In previous knowledge base attempts, we had gone about everything backwards and wrong.

Our team of three hit the ground running! We took a lot of our existing Wiki materials and created articles. We also began creating articles as calls came in and working out the kinks in our KCS practices. And there were plenty. We tweaked the format. We changed the organization. We re-thought which sections we would use. We adapted our processes to accommodate the limitations of the software versus what KCS standards actually tell us to do. Lots of growing pains, but lots of exciting stuff.

In the meantime, we had the remaining members of our service desk team go through the KCS Foundation course and certification. When they got trained, they could create articles, too. In the meantime, our service desk staff and student workers could reference the articles the pilot team had created. We found that people were having remarkable success, especially with those oddball “one off” kinds of calls. A person would get a call on something they had never heard of before and find an article that solved it in minutes. When the person realized how much time was saved, that person became a believer.

We started updating our training to teach new employees to rely more and more on referencing the knowledge and creating more. Two of the original pilot team gravitated into the role of coaches and champions for the process. And eventually, in 2016 I took on the role of knowledge coordinator because of the success and much needed attention our knowledge base grew to require.

Kaliegh presented her KCS journey at HDI Conference & Expo.
Learn more!

Incidentally, around the same time as we were getting our feet off the ground, a server housing our Learning Management System (LMS) knowledge base was hacked. We shut the server off and realized that upgrading the knowledge software would cost quite a bit of money. It seemed silly to spend money on a different knowledge system when we already had our new ticketing software and months of established protocol and tweaking. This group came willingly into the team as well. Our coaches trained them and worked with them to get needed articles going. We didn’t try to convert all the old material; we created new articles as calls arrived.

Momentum was going because we had two groups that had good buy-in and were getting positive results and telling others about the time saved and superior results. This doesn’t mean everyone was on board. Some people in these small groups came kicking and screaming. That really isn’t avoidable. It can be due to personality types, fear that the KB is trying to replace them, or a million other reasons. Those you must try and diagnose and resolve one-on-one. We set expectations and deal with how people meet those expectations as individuals. The team, however, was exceeding expectations.

We diligently continued our KCS expedition and in 2016 the service desk faced our biggest challenge yet. We went from having seven full-time employees in the service desk to just four. And yes, I’m glad you asked; we lost them in a month (luckily to other areas in our IT division). It also happened to be the month before our Fall semester began at WKU. If you have ever worked in higher education, you know August can be a test in strength, tears, and faith. You are probably saying to yourself, “Turn over in service desks isn’t anything new, so what’s the big deal?” We went from having a combined 40 years of experience in the team, all gained while working in our service desk, to just 17 years. Two of the employees that stayed just hit their year mark with us. Our knowledge base was still young, and we still relied heavily on the 23 years of experience our three team members took with them. With the start of the Fall semester quickly approaching, we had to hire and train three full-time staff members.

Luckily, we were able to find new employees and get them trained enough to take calls before the onslaught of support hit our service desk. We expected that our first contact resolution (FCR) rate would drop due to the new employees but understood that is what comes with turnover. Spoiler alert: It didn’t! In fact, we increased our FCR. In 2015 our FCR was 77% and in 2016 we ended the year with 79%. Shocked by these results, I did a bit of digging.

Our LMS can be a sore point for support. You need a deep understanding of the software to have a decent FCR involving tickets with it. I decided to pull the FCR rates concerning our LMS and was blown away again. Our busiest time of year is from August to September, and this is also when we see the majority of our LMS incidents occur. From August 2015 to September 2015, we logged 767 incidents with clients involving our LMS. Our Service Desk resolved 89% without escalation. Fast forward to 2016 and we resolved 91% of them at a service desk level. Once again, we increased. We asked ourselves how this was possible with three brand new employees and two just at their one-year mark. The answer was our knowledge base.

Fast forward to today and you find us with a list of lessons learned, a shelf full of successes, and a thriving knowledge base. If your organization is thinking of taking the KCS plunge, I advise you to take it head on. I will leave you with a list of advice on getting started:

• Start small. You will inevitably have failures and things you want to change about your process in the beginning. Work those out in a small pilot group before expanding out to everyone.
• Get trained. It was vital to our pilot group to understand KCS fully before diving head first into creating our knowledge base.
• Solidify your style guide. Get (mostly) settled on your KCS style guide before expanding your pilot group. There is nothing worse than realizing you want to change a process and then having to get numerous people to adapt to that change.
• Do not force participation. Try not to force outside groups to participate. Let your area’s successes speak for themselves and attract people naturally to the KCS way of life.
• Create a system of encouragement. Do not reward participants for the number of articles they create; rather reward them for the quality and usage of their articles. Don’t turn it into a numbers game. If you push people to produce articles at a particular rate, you will get exactly that, just articles and a lot of duplication of articles to handle. You want to encourage people to contribute when they actually have valuable knowledge. Reward your contributors for their article edit requests, their article usage statistics, and the quality of their articles.
• Use integrated knowledge base software. If possible, use knowledge base software that is already integrated or can be integrated with your ITSM software. The easier it is for your service desk and other employees to access, search, create, and link articles to service incidents, the livelier your knowledge base will be.
  

Kaliegh Averdick is knowledge coordinator for Western Kentucky University's IT division, responsible for their entire knowledge management strategy. This includes coordinating quality knowledge sharing, promoting and guiding knowledge creation, developing and maintaining the knowledge base, and maintaining a knowledge training program. Kaliegh holds HDI certifications in Support Center Analyst, Technical Support Professional, KCS Fundamentals, and KCS Principles. You will be hard-pressed to find anyone more passionate about KCS!