Knowledge-Centered HR Service Delivery

A Brief History of the Evolution from FAQ to Knowledgebase

The concept of knowledgebases and self-service portals has been around for decades. In the early incarnation of knowledgebases, it was nothing but a simple list of questions and answers, often known as Frequently Asked Questions (FAQs). As customer service agents received and answered questions in a support center, they realized that many customers have similar or repeat questions, and so the idea of creating and documenting FAQs was born. This way, customers could help themselves to the answers to the most common questions.

As the case volume increased, it became very difficult for support agents to write and document these FAQs. Customer service representatives did not have the time or bandwidth to develop FAQs; they were focused on resolving issues and meeting SLAs. We then saw the emergence of a new breed of professionals called Knowledge Engineers. These Knowledge Engineers were by profession technical writers and their role was to harvest the knowledge from massive customer support case tracking systems and support agents to create these FAQs.

This period did not last very long, as the core issue of the support agent’s limited bandwidth got worse. In addition to working quickly to resolve a large volume of cases, they now had to meet regularly with Knowledge Engineers to help explain common questions, issues, and answers, and to proofread the FAQs.

It was then quickly recognized that FAQs have to be created from the source - in this case, support agents who handled the issue. As long as these FAQs met a basic standard, they were deemed good for public consumption. This is when Knowledge-Centered Support (KCS) was developed by the Consortium for Service Innovation.

Knowledge-Centered Support

At the high level this is what KCS brought to the world:

In a nutshell, KCS promoted creating and capturing knowledge in a simple format. Support agents were responsible for initially creating these knowledgebase articles. A KCS leader in the organization would develop a set format or template and the rest of the team could simply follow this template to begin filling the knowledgebase with new articles, or updating existing articles with additional information. Sometimes issues considered solved previously may have new manifestations or iterations, requiring a knowledgebase article to be updated – following the “Evolve” loop in the diagram above.

This KCS methodology proved to be very successful, reducing the time service agents spent on repeat questions and resolving issues through an effective knowledgebase. This achieved the organization’s greater goal of higher customer satisfaction. By resolving issues and answering questions faster, support organizations can continuously improve customer satisfaction, manage effective support teams, and retain and grow happier customers.

This has only grown more critical in recent years. Today’s reality is that as soon as we think of a question, we run to do a Google search for the answer. We don’t have the patience to wait for an answer for days and days, especially if we know that knowledge is already documented somewhere. We want to be able to get to it ourselves, and quickly.

Just like Google searches, for the most part these KCS knowledgebases have been context insensitive. This means they don’t really know the customer who is requesting information, and therefore they can’t provide the most relevant answers or personalized results.

The next step in the evolution of knowledgebases is to become context sensitive. What do I mean by that? Essentially, I as a customer (or employee) know that when I have a question, the person or the system on the other end knows all about me, my history, and should not ask me any unnecessary questions. With this contextual setup, I also expect the answers I get are appropriate and relevant to my particular situation - not to a customer who bought a different product, or to an employee who works in a different country.

What does this have to do with HR?

Effective HR Service Delivery organizations are adopting KCS methodology in order to deliver better service to their employees. PeopleDoc’s employee portal and knowledgebase is context sensitive, so the knowledgebase articles can be very precise. With employee data like location, department, role, status, etc., it’s simple to provide personalized, relevant information to the employee, making the entire end-to-end employee experience pleasant.

Systems like PeopleDoc provide analytics to identify key metrics that help HR organizations continuously optimize. For example, if a certain category is generating a higher-than-normal volume of HR tickets, HR business partners might choose to work with their respective organizations to beef up the knowledgebase with appropriate articles in that category. The HR team can review analytics dashboards to determine areas in greater need for articles, or updates to existing articles, and then monitor the effectiveness of the updates by viewing the reduction of relevant tickets.

In Summary

The idea of service delivery is not new. HR teams can take the lessons learned by customer service organizations of the past to build world-class HR service delivery organizations. The KCS Double Loop Process in the diagram is a great starting point for HR service delivery teams to begin discussing how they will harness knowledge and content to provide a better experience for employees.