On Guide Professional and Enteprise, agents can use the Knowledge Capture app to create new articles and flag existing articles for updates. This article describes ideas and best practices for setting up your workflows for created and flagged articles.
- Creating, Flagging, and Publishing with the Knowledge Capture app (by Daniel)
- Knowledge Capture publishing workflow (by Andrew)
- Knowledge Capture publishing workflow (by Anton)
- multilingual content creation workflow (by Jacob)
- Our KCS implementation with Zendesk (by Cale)
- How we create new content using the KC app in the ticketing process (by Mary and Sahar)
Setting up your workflow for created articles
Agents can create new articles using the Knowledge Capture app. Before they do so, you should think about where you want these new articles to be created and who will be responsible for reviewing and publishing them.
If your agents have permission to publish their own content directly to any section in the knowledge base, and you don't require review or approval, then you don't have much to think about. Agents can simply publish articles where they need to be, using the app, and it's done.
Deciding where to create new articles
When agents create articles through the app, they use a template to do so. You need to set up any templates you want before agents can create articles (see Creating templates).
Your template can determine the status of the article and where it's created, among other things. These options are not locked when an agent creates an article based on your template, but you can train your agents on how you want them to interact with the template, and what decisions, if any, they should make in the process.
You can create your template according to the workflow you want to implement. There are many ways you can set up your workflow for newly created articles, but here are two ideas you might consider:
- Creating Drafts for review
If articles are created as Draft status, they appear in the Drafts list, and only Guide managers can access to the list of drafts. Agents cannot navigate to draft articles in your Help Center. Publishers can filter the drafts list as needed. You'll still need to select a section for the article in your template, but the article won't appear in that section while it's still a draft, so agents won't see it.
- Publishing to an internal, agent-only section for review
You can set up an internal, agent-only section where agents can create published articles so that external users cannot view articles before they are ready (see Restricting access to knowledge base content). This seems to be the most popular workflow choice, based on what we've seen. You might call the section "Work in Progress" or "For Review."
One advantage to this is that articles are visible to agents in your Help Center and are searchable and flaggable in the KC app while they are waiting for review. Some teams leave new articles in an internal section until they can document a complete solution or validate a solution. With this approach, agents can give feedback on the internal article and improve it. This is a good way to gauge article usage and validate solutions before publishing publicly. While it's still internal, agents can copy and paste into the ticket even though they can't link to it directly in the public ticket comment.
Whether you are creating new articles as drafts or published, you might want to add labels to your templates for tracking purposes. For example, you might add a "needs_review" label to your template. If you are creating content in multiple languages, you can add language-specific labels, such as "needs_review_fr" and "needs_review_es."
Creating new articles
When agents create new articles, you might want them to self-publish so that the articles are available immediatley. Or you might decide to have a review process for new content by a group of approvers or publishers.
If agents are self-publishing they can simply create a new, select a section for it, and make it live. If agents, however, create content for another group to review and publish, then you might rely on your template to create the article in the right place. Agents can create articles only in sections where they have permission. So agents will not be able to change the section set in the template if they do not have permission to create articles in other sections.
Here's another approach, that's a bit of a hybrid. What we do internally at Zendesk is ask tier 2 and 3 agents, who tend to be SMEs and handle more advanced, technical issues, to self-publish when they need to create a new article. Our tier 1 agents, on the other hand, deal with higher volume and a broader range of issues, so we ask them to suggest articles for creation.
They do so by flagging a placeholder article instead of actually creating a new article. The placeholder article has sections to fill in, similar to a template, but the agents add comments with information for each section. Then they submit the flagged "suggested article" article and a ticket is created. The ticket is routed by a trigger to the publishers group, who review the suggestion and all the info, then create an article.
Alerting publishers about new articles for review
Based on Knowledge Capture app customer feedback about workflows, most teams have a separate group that is responsible for reviewing and publishing articles created through the KC app. It's important to decide how this team will learn about new articles that are ready for review. Deciding how to monitor for new articles might depend on where articles are created.
- Monitoring Draft status articles
If articles are created as Draft status, they appear in the Drafts list, and only Guide managers can access them. You can have the team responsible for reviewing and publishing monitor the Drafts list in Guide admin. They can add a filter to the drafts list so that they focus on the drafts created through the app that need their attention (see Using article lists).
For example, if drafts are created in an internal "WIP" section, add a filter for that section. Or if drafts are created with a specific label inherited from the template, such as "needs_review," filter on the tag. If you are on Guide Professional, you can save your articles list.
- Monitoring Published status articles
If articles are created as published status in an internal section, then they appear in your Help Center. You can have the team responsible for reviewing and publishing subscribe to the section where articles are published so that they know when a new article is created and needs their attention (see Following content in the knowledge base).
If you don't want all agents to see the section for new content, you can create a user segment so that the section is only visible to agent in a specific group or with a specific tag (see Creating user segments).
And just as with drafts, you can have the team use article lists to monitor new articles that need their attention. They can filter by section or tag or created date, for example.
Reviewing new articles
- Writing and grammar
- Style guide
- Template compliance
- Duplicate or similar articles
- Accuracy
If an article needs to go back to the author or to an SME for an additional review, the publisher can route it to the appropriate person. You might consider creating additional internal sections or using labels for this part of the workflow as well, if it's a regular part of the process.
Some teams want time-to-publish to be as short as possible, so they review and approve new articles right away. Other teams might leave new articles in a work in progress section until they can document a complete solution or validate a solution. Or, maybe you take a hybrid approach, and allow for quick publishing and work-in-progress articles, depending on the content.
Publishing new articles
When a new article is complete, has been reviewed, and is ready to go, the team responsible for publishing new articles can update the settings on the article and move it to a public section. Or, for an internal knowledge base, the publisher can just move it to the appropriate internal section.
Make sure your publishers have the permission they need to publish into the right sections. The easiest option is to make them Guide Managers so that they have access to all sections (see Understanding Guide roles and setting permissions). Alternatively, you can make specific sections editable by agents as needed (see Allowing agents to add, edit, and delete articles).
- Change the article status to Published, if it's not already.
- Remove any labels used during the creation and review process.
- Remove any notes that are included in your template, if they haven't already been removed.
- Select the appropriate section for publishing.
Setting up your workflow for flagged articles
Agents can add feedback to articles that need updates using the Knowledge Capture app. When an agent adds feedback, the article is considered flagged and a ticket is created. You should decide where those tickets go and who is responsible for updating flagged articles.
Routing tickets for flagged articles
You might want to have agents assign flagged tickets directly to the author of the article. But if you want all flagged tickets to go to a specific team, an easy way to route flagged tickets is to create a trigger that sends the ticket to a specific group.
For example, you might create a Publishers group and route all flagged tickets to them. That group would be responsible for updating the articles. Or they might pass the ticket to the author or an SME to make the update.
Reviewing and updating flagged articles
Once the person responsible for updating the article has a flagged ticket, they can make the updates as indicated by the article feedback in the ticket. They can click the edit link from the ticket to open the article in edit mode.
If the reviewer has a question, or if there is another reviewer in the process, the ticket can be assigned back to another agent. You might consider creating a macro for this, if it's a standard part of the process. Using tickets makes it easy to track and process articles that need updates.
You need to make sure the team responsible for updating flagged articles has permission to edit articles in Help Center. Again, the easiest option is to make them Guide Managers so that they have access to all sections (see Understanding Guide roles and setting permissions). Alternatively, you can make specific sections editable by agents as needed (see Allowing agents to add, edit, and delete articles).
Solving tickets for flagged articles
It's a good idea to update the agent who originally flagged the article so that they know the article has been updated. Updating the agent completes the feedback cycle so the agent knows the article is up-to-date and accurate. And they also know that their contribution was used and appreciated.
When the article has been updated, and you've notified anyone who needs to be notified, it's time to solve the flagged ticket.
21 Comments
Hi Jennifer,
Can you point me to the ZD Community that discusses Team Publishing. I noticed we now have those options available and I would like to post Qs/Concerns once we start testing it.
Hi Mary!
Yes, the Team Publishing community is here:
https://support.zendesk.com/hc/en-us/community/topics/115000561748
Hi,
In our help center, one of the most used features is the community.
And often times, there is already a answer to a ticket in a post on our community.
But when the agent insert the community post link, the Knowledge capture app don't recognize that as a link =/.
Ex:. https://ajuda.skyhub.com.br/hc/pt-br/community/posts/360001304306-Integra%C3%A7%C3%A3o-dos-Pedidos-B2W-para-o-SkyHub
Is there a way to make the KCA get the links from the community posts as well?
Good idea that we would support!
I want to add that any 3rd party link should be allowed to be added thru the KC appl also. This would allow the KC appl to include these links in the metrics for reporting purposes.
I'm curious if anyone has come up with some workflows for routing flagged article tickets to multiple groups based on where the ticket is located. I'm trying to map out how I could use this process on an instance that has a lot of separate teams that may have completely different knowledge partners in their respective organization. Looking at the available details on the tickets created from the Knowledge Capture app, it appears that there isn't much to pull from unless the article or comments contain certain keywords that helps isolate an article to a specific team.
Has anyone built a workflow like this to support flagging from multiple teams?
I've been thinking about your question, Daniel, and one option is to create a trigger that looks at keywords in the ticket title:
However, I recognize that in complex content ecosystems this wouldn't likely be sustainable.
For any others facing the same issue, Daniel created this feature request with a great outline of his use case and ideal workflows. Feel free to chime in with your support!
Hi Zendesk, the note in this section of the article (https://support.zendesk.com/hc/en-us/articles/115011968988#ariaid-title2) states that you cannot disable the ability to create articles in the app, but you can!
Thanks for bringing that to our attention, Lila! The documentation team is updating the article as we speak.
Yep, all set now!
That's a setting that was added some time after the KC app was released and we missed updating the note here.
Thanks again for letting us know, Lila!
Hi,
Is it possible to show an example of your placeholder template that you use at Zendesk? It would help to have an example.
Thanks
Here's another approach, that's a bit of a hybrid. What we do internally at Zendesk is ask tier 2 and 3 agents, who tend to be SMEs and handle more advanced, technical issues, to self-publish when they need to create a new article. Our tier 1 agents, on the other hand, deal with higher volume and a broader range of issues, so we ask them to suggest articles for creation.
They do so by flagging a placeholder article instead of actually creating a new article. The placeholder article has sections to fill in, similar to a template, but the agents add comments with information for each section. Then they submit the flagged "suggested article" article and a ticket is created. The ticket is routed by a trigger to the publishers group, who review the suggestion and all the info, then create an article.
Hi, Thomas! Sure, I can definitely give an overview. Our "placeholder" article prompts Agents to input the following:
1. Question or issue the customer described
2. Answer or resolution steps
3. Cause (if known)
4. Solution description (include screenshots if needed)
5. Other considerations
These are aligned with KCS best practices, as outlined here. I hope that helps get you started, but if you have any other questions, let me know!
Is it possible to create a ticket for new articles, similar to when flagging?
I believe this will make the workflow easier and centralized vs each team member needing to monitor/subscribe.
Hey Jacques, I think I understand where you're going, but just to clarify, is your hope to keep Agents alerted to and aware of newly created articles?
Hi Madison. Yes. Currently with a flagged article we can request more info via the linked tcket and when it's closed, the angent knows the changes are done.
With new articles you either have to email the agent direct or manually create a ticket if you need to keep a trail.
Thx, J
Thanks for clarifying, Jacques! Unfortunately, I don't have a great solution for you. We manually create tickets in this case at Zendesk, or encourage those who might need to have visibility to follow the Sections where articles are being published. There might be a way to do this via API, by setting up a call that generates a ticket whenever a new article is created. It would likely have to pull that information incrementally, though, and on a regularly recurring basis! Sorry to be the bearer of bad news on this one. Let me know if you have any additional questions.
Thanks Madison. Have requested similar steps here as you mentioned, but there is always that one that slips through with manual steps.
This something that could be added as an enhancement request?
I totally understand, Jacques! I took a look around our Product Feedback forum and couldn't find an existing request for something of this nature. I'd recommend that you create a new post in the Guide Product Feedback topic!
Jacques, please post a link to your feedback entry here so folks can upvote it (myself included!)
Post created:
https://support.zendesk.com/hc/en-us/community/posts/360030194013-Enhancement-for-Knowledge-Capture-app
How can you reoute the ticket via a notification to the AUthor of the article in question? Do you have an example rule?
Hey Mary! Great question, but unfortunately I don't know of any automated way to do this. There aren't any mechanisms built into triggers to detect who the author article is, or take action on it to send to that person. We manually triage these requests for updates at Zendesk.
Please sign in to leave a comment.