- 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 admins 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 admins 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
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 admins 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.
Is it possible to send a notification when a new article is created so the team knows that it needs to be reviewed/published?
It is possible when you assign a team or agent for that specific article. The agent will receive an email notification with a link to the article. Guide admins can view a list of all their assigned articles. Users who are not Guide admins cannot view article lists, so they will need the direct URL to access the article.
The email notifications should be sent automatically whenever an article is assigned to someone for review -- see Assigning or reassigning articles with Team Publishing
Is there a way to add a tag to a ticket if an agent links an article from the KC app? I don't see a source to identify update from KC in triggers.
There isn't a tagging mechanism associated with the KC app at present, so it's not possible to tag tickets based on usage of the app.
As a workaround, you could create a macro and train your users to use it each time they've added / link an article via the app, the macro appending a ticket tag that speaks to app usage, but this would be a manual process and rely on users application to work effectively.
Out of curiosity, what's the use case for adding a tag? I'm wondering if the Linked article information in the Knowledge Capture dataset and dashboard might get you what you need. Analyzing your Knowledge or Knowledge Capture app activity.
It's a question from our product management and the reason is to be able to identify specific tickets for review. I see ticket id is an available field in KC app reports and will try to set up a report with some more details and see what I get.
Please sign in to leave a comment.