Creating, Flagging, and Publishing with Knowledge Capture Oh My!

I wanted to share how our team is doing Knowledge Sharing today.  We have a lot going on in our knowledge process, so I'm not going to list out specific steps on how to build this, but I'll be giving a high level overview of most of our process.  Some of the steps may make a lot of sense for you and your teams, others might not. However, I hope that this helps some of you improve your knowledge experience. 

Background

We've had variations of this since before it was even a concept being looked at within Zendesk.  Our team worked closely with our account rep to introduce them to Knowledge Centered Support (KCS) methodologies and we heard that many teams at Zendesk completed this training themselves and started their own knowledge journey, over the following years there have been many versions of this app.

We are just getting to a place were we can use the features in Zendesk, but the tips should still apply to your teams with the newest release from the Knowledge team.

We've also done all kinds of crazy stuff like writing articles in the ticket description and using the Ticket to Help Center app to create content.  Don't do that, it was rough.  We've also had dedicated sections for parts of our workflow to hold articles (this even included archived articles before we could actually archive articles) and we've kept some of this around.  

Setup

Our workflows require some setup in Zendesk to support them. 

• We have a Category for all new articles to pass through. This category has two sections: Unconfirmed and In Review. Unconfirmed can be managed by all agents. End users cannot see these articles. In Review and all other sections can only be managed by Guide managers. Visibility is determined by user segments. In Review is still limited to agent eyes only.
  
  
• We have two templates for Question and Answer format.  One is for internal articles, the other is for external articles.
   
• We use the Zendesk features for knowledge sharing.
   
• We have a customized Web Widget used solely for article feedback on our articles.
  
  
• We have a Form called Knowledge Article
  
  
• We have a role that allows for some of our agents to Manage Guide
• We have a group that includes our knowledge managers
  
  
• We have Triggers in place to automatically set web widget, and knowledge capture tickets to the Knowledge Article Form, and set to the group to our knowledge group.

Creating Article Workflow

Most articles are created from Knowledge.  This is done using a one of our templates.  All agents can only create tickets in Unconfirmed.  We create all articles as internal, published articles.  We don’t use drafts because we want our articles to be constantly iterated on through our flagging process. 

We support “good enough” article creation. If an article doesn’t exist, we’d rather an article exist than be perfect.  An example article might be: 

Question: 

How do I solve this problem?

Answer:

Ask Daniel for help. 

It’s not the solution, but it is a solution to get the agent on the right step.  

Only our Knowledge team can create articles in sections outside of Unconfirmed. If an article needs to be pushed into the Help Center faster, an agent can create a Knowledge Article ticket to request the article is updated and published in a certain category/section. 

Flagging Article Workflow

We promote flagging a lot.  If an article needs improvement we put the ownership on the entire team to help improve knowledge.  Agents can add comments to an article and a ticket is created to update the article.  If an article is in Unconfirmed, the agent can update the article directly. 

Each flagged article creates a ticket.  This ticket is routed you our Knowledge team who reviews each article for duplicates, style guide, template, compliance, etc.  They apply the changes indicated by the flag.  If the article still seems like it is incomplete, they may elect to leave it until another flag comes in, or if they know the answer, they can resolve it themselves. 

The reason we don’t push for 100% perfection is that some articles aren’t used that often.  We want to spend our energy on content that is in use, so we make updates based on current feedback and only on feedback. This works for us since most of our articles are internal facing only. 

In addition, we have the web widget embedded into Zendesk.  We have it hidden by default, but it shows up by clicking a link at the bottom of each article that asks for Article Feedback.  This allows for us to capture the URL of the article when the web widget ticket is created and allows for non-agents to provide feedback on articles.  In these cases, we’ll make the article as perfect as we can since it’s externally facing.   Web widget tickets are routed via trigger to the right form, and group for knowledge updates. 

Publishing Workflow

Sometimes newly created tickets need to go quickly from unconfirmed into more prominent section.  We allow our team to submit Knowledge Article tickets to request this.  In addition, we have workflows in place to review our Unconfirmed sections for the most viewed articles.  If they are being used, we clean them up and move them into the greater knowledge base.  If an article has too few views, we don’t put the effort in. 

If an article needs additional review from a subject matter expert, it may sit in the In Review section for a while.  This section is internal, but it is locked down for edits while it is primed for release to the broader Help Center. Subject Matter Experts don't have to be on the Knowledge team, they just have to know if the information in the article is correct and valid. 

For external content, we have a style guide on how articles should look.  In this case, we check all the boxes and make sure articles look their best before publishing them. 

Linking and Reporting

This is the area where we are looking to gain the most.  

We look at link rate, flag rate, and create rate to understand our knowledge usage.  We also started doing some tracking with Link Accuracy.  This isn’t automatic in Zendesk, but we are pulling a few random tickets out to validate that the knowledge process was followed appropriately.  Based on these random samples, we’ll give a score for Link Accuracy to our agents. 

We also have a service level set on our article tickets.  We use Pausable Update of 3 days. This promotes active improvement on our articles over time and allows us to pause the service level clock if we just can’t progress an article ticket. Our knowledge team has these interwoven into their standard tickets. 

One thing that is lacking is view counts.  Link metrics get us by a bit with these because most of our articles are used by agents, however, we do have a limited view into our customer viewing habits.  Google Analytics is a solution, but I’d rather see a baked in ability to see views so I could rank which articles are worth working on.

A lot of our processes are about not spending time on articles with low usage.  This is important for my team because we are much smaller than we used to be.  Adding knowledge workflows on top of normal work can add a lot of overhead.  Our message is that knowledge isn’t in addition to our work, but a core part of how we work.