Scaling your Support Team - Building an internal Knowledge Base

One of the most important aspects of a quality Support team is becoming a scalable function since, as the company grows, it is vital to ensure that the team knows how to handle the vast majority of issues. Another important element is keeping employees engaged, which in return creates dedicated company members and better results all around (both for the customers and for the company).

When it comes to the Support team, keeping them engaged is even more important and crucial, as most of their work is reactive, and the members of the team usually see their role as a stepping stone to a different position.

More often than not, we may encounter frustrated or even angry customers that should be handled with care.

In one of the companies where I managed the Support Team, I noticed that our internal Knowledge Base is a mess -  a lot of information scattered around multiple locations made it really hard for the team to find the exact troubleshooting article they need. In most cases, the articles were outdated and unusable. 

When translating this gap into numbers, this caused a huge delay in our time to resolution, in the number of tickets each agent could handle, and most importantly - in poor customer satisfaction. I saw here an opportunity for a win-win situation: having a scalable team that knows how to quickly manage tickets while keeping my employees engaged. 

Tackling the knowledge base was a challenging project, mostly due to its complexity and the team's willingness to use it. A survey that I sent to the Support department & Customer Success department showed that more than 80% of them do not wish to use the knowledge base because they are unable to find the relevant, correct information they require. 

I saw here an opportunity for a win-win situation: having a scalable team that knows how to quickly manage tickets while keeping my employees engaged. 

The first step was finding a proper owner for the project, and harnessing them to the job - it was crucial that they will understand that this project is entirely their own. We kicked the project off together and began defining the targets, goals, and timelines that should be met in order for the project to be successful. We set achievable KPIs, created a dedicated JIRA board and built a working Gantt. 

After we've set the ground rules for the project’s success, we created different templates for the articles the knowledge base will encompass: General information, Troubleshooting steps, Deep dives, etc’. 

We removed articles that were no longer relevant and cleared the clutter. Each existing article was categorized properly and an approval flow was created in order to control the newly added knowledge. We understood that in order to make it work, we had to ensure that the team will understand the reason for this renovation process so they will help out - each team member was assigned a category of articles they needed to either create or re-write.

It was crucial that they will understand that this project is entirely their own

On a weekly basis, the owner updated me about the progress of the project. The success of a project at this scale depends on managerial support, meaning it was my responsibility as the manager to ensure the team is on top of their work. At the team’s weekly meeting, the owner presented the project and made sure the team is updated with its progress. At key points of the project, we have sent out additional surveys to make sure that our progress is noticeable and acceptable by others. 

After a couple of months, we saw that the workload is too much for a single person to handle, especially when it is an extra-curriculum task and not part of the day-to-day work. At that point, I’ve decided to assign another team member to assist the owner in the progress, and as part of their project role - they also assigned tasks directly to their assistant. This helped in making sure we have another set of eyes on the project while having another engaged employee.

In the middle of the project, we started checking for KPI improvements. We saw that when employees used the knowledge base - they solved the problem faster and the customers were happier. This was a great result and confirmation that we are on the right track.

When employees used the knowledge base - they solved the problem faster

When the project came close to its completion, it was no longer supposed to be the owner’s responsibility, we started thinking about maintenance. Without maintaining the articles and the work we have done - our project was doomed to failure in a few months’ time. We decided that each category owner will change every 3 months, so each employee will be responsible for maintaining a different set of articles over a period of time. When it comes to new articles - we already had the templates and approval flow that was created earlier.

After the end date of the project, we reviewed the work we have accomplished. From a messy knowledge base that the entire customer-facing operation suffered from in the beginning, we’ve created a category based pool of information that was constantly used by our teams and engaged our employees for many months to come, and most importantly - made our customers happier.