CX Training and Knowledge Coordinator, Clio

We are introducing KCS to a fairly mature CX department (~20 front line agents, ~30 other roles, a popular Help Center with ~700 articles). We began the first wave of a two wave implementation at the beginning of September.

We currently have three main KCS roles:

• Reader (can view, link, and flag articles)
• Contributor (can create and edit internal articles, external articles need to be reviewed by their Coach)
• Publisher (can create and edit external articles, can be a Coach)

New hires start as Readers and progress to Contributor level after a few KCS training sessions during their on-boarding.

Currently, all of our KCS articles are internal, so Contributors and Publishers have, essentially, the same permissions. However, Contributors have Coaches who review all their articles.

Contributors level up to Publisher after receiving over 90% on their coach-administered AQI report for 4 consecutive weeks (or after three weeks of 100% performance), and after proving that they take a KCS approach (capturing the customer’s issue in internal notes, searching the Knowledge Capture App) to each customer interaction. Coaches administer the AQI at weekly meetings.

We use three templates for creating new articles:

• How-to
• Q&A
• Issue/Solution

Here is our article creation workflow:

You can read more about our KCS implementation here.

Knowledge Manager, Bold Commerce

My Role was created in March of this year when I was hired so the roll and all processes have been developed by me. Prior to this all of Client Success had access and authorization to create, publish and edit articles so as you can imagine it was quite all over the place when I got here. I have been through and edited all content which currently comprises 1073 articles. I still go through the article history on a weekly basis to go through any articles that are being edited and created without my knowledge. People are getting used to having this role now though, it’s just a bit of a growing process.

My background includes:

• Seven years as Knowledge Manager for a previous Company
• Three years as a Site Publisher for the Same Company
• Web Development Degree
• 23 years of Web Development and Graphic experience
• 25 years of Customer Service Experience
• Management experience in three different companies as well as operating my own business

How do you know what content to create?

My role is very new in this Company so it is a bit of a growing process right now. Usually I am advised of the need for new content by the team that develops our apps or our client support team. I also analyze search terms and customer feedback to determine a need.

How is your team structured for creating new articles?

In our Company, my role is currently the entire team.

What are the roles? Are other teams involved?

Our Company consists of a few different areas, Client Success of which I am a part, Marketing, App Development and Professional Services. All departments can communicate new content or changes to existing content to me but have no direct involvement in actually creating it. Something they will write the content and I will need to edit it ensuring it follows the guidelines and are consistent.

What is the workflow for new article creation?

Once I become aware of the need for new content I determine placement in the navigation. I then walk through the app myself, document the steps, take screenshots and edit them, I create the content including all HTML and CSS and ensure it follows our guidelines, is consistent and follows w3c standards. I then test it and make it live. I then let the requester know the link and they advise if anything needs to be added or adjusted.

Is there an approval process?

No, my role has final say in this but I work with the requester to ensure everything was captured correctly.

Is there an approval process?

Not at this time, I have been able to turn around all requests the same day or the following morning if it is provided late in the day.

Let me know if you have any questions!

Support Manager, Episerver

We create content based on the following criteria for one of my teams

• Could someone else have the same question or problem in the future?
• Is this a code sample?
• Has the same question been asked multiple times?
• Have I contributed anything to the knowledge base this week?

We rely on our support team to create articles based on the above criteria. Using the knowledge capture app, we have a template with the specified format that articles should be in. We require a description and a resolution and format the article accordingly when displayed. Below is a screenshot of our template.

View of the Template:

View of a published article:

For article workflow, we ask agents to create articles in an agent only area and mark them as a draft. When the article is ready to be published, a manager reviews the article contents and publishes and moves the article to an appropriate category and section. We also create placeholder articles in an agent only area called Future KB’s. This area is for agents who spot a ticket that should be converted to a KB at a later time to create a placeholder to come back to later to create the article. We have it setup that they provide a title for the article and in the body, use the ticket number for reference.

KCS Program Manager - Solve Loop and KCS Program Manager, Republic Wireless

At Republic Wireless, we take a demand driven approach to creating content through our Knowledge Centered Service (KCS) program. When we receive a question, issue, etc. from one of our platforms (i.e. tickets, chat, community, social, etc.) we use that as an opportunity to use or create knowledge. If nothing currently exists within our Help Center, we create new content based on that interaction. Content is created in one of three ways based on the specific context that we have from the interaction; How to’s, Questions and Answers, and Solutions.

In our program, we’re currently in the middle of adoption with ~42% of our agents currently trained to use KCS. Within the next two weeks, we will have ~75% trained. These agents make up our TAC, Customer Advocacy, Billing, and Escalation teams which ensures that we are creating content from all of our support channels.

In accordance with the KCS methodology, our agents are broken up into small teams with a KCS Coach. Agents earn their publishing license by demonstrating an understanding of our content standards and workflow. Agents that aren’t licensed to publish, put new content in a section that publishers and coaches review regularly. Agents that are licensed to publish, can do so without any additional approvals. It’s important to note that all agents have the opportunity to become licensed and there is nothing restricting an agent from earning their license. The content created by these agents is considered our “just-in-time” content (KCS Solve Loop content).

Through our data reporting, we’re able to identify the content that is used most often and develop a plan to evolve that content (in KCS terms, Evolve Loop content). This involves reviewing and prioritizing the most used just-in-time content, collaborating with multiple departments and subject matter experts, and creating a content strategy. Since knowledge is constantly changing, thus making it difficult to keep up with, by evolving only the most used content, we’re ensuring our work is more meaningful and purely data driven. It is this necessary, yet delicate balance between the just-in-time content and the evolve content that sustains a healthy self-serving Help Center. At this point in our adoption, we are just getting started with the evolve content process.

In addition to identifying popular content to focus on in our Evolve Loop, we also look at metrics related to agent participation. We review create, link, and flag events and have a goal of 65-85% of our member interactions having a knowledge event associated with them.

Though we’re still early in our adoption, we’ve already seen an impact through our demand-driven, KCS approach. Previously we had two content creators that spent their time creating and working on content that we assumed was relevant to our members. We now have 51 agents creating content based on actual questions and issues that we see. In 2 months time, we have nearly quadrupled the amount of content in our knowledge base. Stack that on top of improvements that we’ve made to unify our search to encompass both our Help Center and online Community content, we’re driving up our self-service and peer-to-peer service rates all through the existence and use of knowledge.

Documentation Manager, Zift Solutions

Business Analytics Director and Co-founder, smm3

As an onshore Zendesk consultant, I'm co-managing Zendesk at the largest telecom brand in Eastern Europe. We are relying on KCS methodology (Knowledge Centered Service), which aims to make content creation an easy routine process. In the paradigm of KCS that we are applying for our client, content creation is seen a demand-driven process. While using knowledge base (KB) articles for solving tickets agents can see eventual gaps in the articles and fulfill such gaps.

We are also performing monthly optimization in KB (known in KCS as ’Evolve loop’) based on searching stats from Zendesk Reports. Search queries with no results or with low click rates are very helpful for understanding where new articles are more likely to be created. Following KCS principles we have build a licensing model with 3-level roles (KCS I, KCS II, KCS III). These roles are regulating who is allowed to create, modify and publish KB drafts and articles based on elaborated ‘Content Standard’ guide. KCS Coach is responsible for validating KB drafts before publishing. Experienced employees from other departments are sometimes involved in the process as Knowledge Domain Experts for the articles validation purpose.

P.S. Following KCS requirements we have developed special Zendesk application. It fills the missing link between knowledge creation (Guide) and tickets solving (Support). Our 'Guide to Support' app converts user comments to articles in the Knowledge base and posts and comments in the Community into regular tickets. Further information on the app can be found here.

Operations Manager, Plesk

Roles and responsibilities

We have 3 groups of engineers with corresponding groups in Zendesk:

• Candidate - newbies, who joined the team just recently and only able to create DRAFT and reuse existing knowledge.
• Approver - an experienced engineer who validates DRAFT from the technical point of view and across content standard.
• Publisher - the most experienced engineer who may publish articles externally.

We do have two categories in HC:

• Knowledge Triage - internal section
• Public - section available to customers. With User Segments in guide, we allow only Publishers to modify articles in that group

Quality

We have a group of coaches in order to verify the quality of the processes & articles. We follow RQI approach. We use PlayVox extension for that. We select a pool of tickets with created/flagged/linked articles and set evaluate thematic is a KPI for engineers

Reporting

We track the following:

KBC - knowledge base coverage - how much tickets are solved with existing articles

PR - participation rate - that % of tickets has linked article

TTP - time to publish - % of articles published externally within X hours

KCS reuse per week - the most popular articles with most # of linked tickets. Top articles passed to engineering to verify if the issue is a bug and need to be fixed ASAP.

Also, you can use

Knowledge and Process Program Manager, Box

At Box, our goal in creating content is to capture the lessons learned in our direct customer interactions to both better share knowledge throughout our team and deflect future support tickets by giving customers the answers they need without needing us to contact us directly. That goal drives the processes for content creation.

We hope to empower our frontline agents to be the primary drivers of what content is created by giving them the tools and bandwidth required to write and publish impactful troubleshooting material. Agents are tasked with identifying gaps in our Knowledge Base through their conversations with customers. They should ask questions like "is this an issue other customers are likely to experience" or "can I improve the wording of an existing article to make resolution steps more clear". We trust our agents to bring the voice of the customer to Product and Engineering teams, and they should be doing the same for driving the direction of our Knowledge Base.

In order to maintain a high quality level in the content we produce, there is a multi-step process before anything reaches our public Knowledge Base. First, an Agent (or Author) will write up a draft detailing the problem, troubleshooting steps and finally, the root cause of the issue. Next, an Editor will apply our style guide and check for clarity in the steps and description given. Finally, we will run our more technical articles by a Subject Matter Expert, who will make the final approval. The article is then published.

This process should allow for both the rapid creation of content while easing concerns about accuracy and style. We are still in the early stages of our increased emphasis on Knowledge Content Creation, but we are hoping to have all valid drafts submitted by agents published within 48-72 hours. As the process becomes more ingrained in our team, we will reduce this turnaround time. The processes, like the content created within them, will be changing and adapting with our team and with Box.

Customer Care Operations, Fossil

We involve our agents heavily in the knowledge creation process. Our first instinct when we don’t know the answer is to hit up the group chat for help, so when we started out building our knowledge base, we kept a close eye on what people were asking about in that channel. We started to build content around that, and once we reached a critical mass of knowledge, began to require agents to search the knowledge base before sending their question to the group chat. That’s reinforced a reliance on the internal knowledge base in Guide, and shifted us toward using the group chat only for new issues.

These days, we still find new knowledge needs through that chat. However, as our agents got more familiar with Knowledge Capture and Guide, they’ve started using those tools to request information directly. Knowledge Capture allows agents to submit their own articles, and we even welcome incomplete submissions simply as a way of tracking needs that an agent may not have the answer for yet. Agents can also comment on articles directly in Guide, which allows us to create a ticket from the comment and assign it to our knowledge management team. From there, we can chase down the answer ourselves, or by collaborating with Light Agents in other areas of the business, then update the KB. We close the loop by posting a reply to the agent’s article comment that updates them on the answer to their question.

KB development works best when you involve the teams that are on the front lines and hearing directly from customers. We’re glad Zendesk has provided tools that help us tap that collective knowledge and build something great out of it

Knowledge Manager and Support Operations Manager, Veeva

How do you create new content?

We have integrated KM & KCS into the ticketing process. Our Agents are using Knowledge Capture to:

1. Search & Review articles for accuracy & relevancy.
2. Add articles to resolve & close a ticket.
3. Create new articles using two HTML templates.
4. Provide feedback on articles for content maintenance.

How do you know what content to create?

The Agent reads through tickets to see which topics lend themselves to articles that can be used by multiple customers. In addition, reoccurring questions or problems lend themselves to new articles. We group related articles into Knowledge Collection articles. This way customers bookmark one article and can refresh it to get an updated list of articles. Example: All product errors & related solution articles, all product tutorials, all product webinars, Product Q&As, etc.

How is your team structured for creating new articles?

We have three geographic regions of Agents that handle tickets. Once Agents are enabled & have technical background, they can start authoring articles. The Knowledge Manager or KCS Coach provides enablement on the workflow for creating, reviewing, & publishing articles. We have 3 levels of Agents:

• KCS I (Create) - submit all articles for technical review to team SMEs and then for quality review
• KCS II (Create & Review) - have the technical skills to author the article but must submit articles for quality review
• KCS III (Create, Review & Publish) - can Create – Review – Publish all articles

The Knowledge Manager performs the quality review & publishes the article. We use Article Quality Index (scoring criteria) to score articles created by KCS III to be sure that the articles meet at least an 85% score. Eventually, we want all Agents to be at the KCS III level to reduce Time-to-Publish (T2P). Article maintenance is done through the Knowledge Capture Feedback feature for KCS III and eventually everyone once they are promoted to that level. New Agents use the KM workflow & KCS Levels until that time.

Are other teams involved?

Customer Success Managers and Level 1 Agents can now submit articles however, they must use the same workflow to get articles approved before publishing. They can advance through the KCS Levels. Our Customer Success Managers (internal) must submit all content through the Knowledge Manager who works with each product SME (to verify technical content) to publish the articles.

What is the workflow for new article creation?

There are four basic steps to the workflow:

• Submit article for Technical Review – add technical review label to article
• Submit article for Quality Review – add quality review label to article
• Publish the Article – all articles marked with QC label (quality check)
• Archive the article – put article into Draft status, and classified into Archive section

To submit an article for technical review, the Agent adds a “technical review” label to the article. The team leads have Manage Articles permission and can set up a filter to find these articles by the label. Once technical review is complete & the Agent updates the article with any changes, the author removes the “technical review” label and adds the “quality review” label. The Knowledge Manager (KM) has a filter to search for these articles and makes changes as needed. The KM sends an email to the author to let him/her know the article is published. The KM adds the QC label to the article and publishes it.

Eventually, most of our Agents will get promoted to KCS III and be able to publish their own content. At that time, we will rely on Knowledge Capture Feedback to maintain the article relevancy, accuracy, and technical content.

Are there any metrics (such as time-to-publish) that you track?

Yes. We maintain an internal wiki page that lists various KM metrics reports that are transparent to the entire team. We track the following:

• # of articles in Draft & Publish per Agent, Region, for month/quarter
• # of articles that went through quality review per Agent, Region, for month/quarter
• # articles created for each Product for month/quarter
• # tickets vs # articles by Product area to do Gap Analysis per month – we have aligned our ticket product areas with the ZD Guide categories & sections
• Knowledge Capture metrics - # Creates, # Links, # Feedback, by Agent by Region, for month/quarter
• Articles with most accesses from our Help Center – use Zendesk Explore or Google Analytics
• Measure Agent performance by finding # article accesses & # articles added to (linked to) tickets
• We hope to use Answer Bot also to measure ticket deflections along with post ticket feedback that asks customer Q about finding articles in KB that prevented opening of a ticket
• Measure productivity - # articles created on average per Agent per month
• Distribution of articles by product & by region to show growth of KB overall and by product
• Measure # articles in customer-facing KB and # articles in our INTERNAL KB