Workflows for created and flagged articles using the Knowledge Capture app (Guide Professional and Enterprise)

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.

This article contains the following sections:

• Setting up your workflow for created articles
• Setting up your workflow for flagged articles

Also, check out these workflow community tips from Knowledge Capture app users:

• 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.

But if your team is like most teams, where the responsibility for reviewing and publishing knowledge lies with another team or special group of agents, then actually creating the article through the app is only part of the job. You'll want to set up a workflow for reviewing and publishing articles after agents create them.

Note: If don't want agents to create articles using the app, you can disable that option.

This section covers the following topics:

• Deciding where to create new articles
• Creating new articles
• Alerting publishers about new articles for review
• Reviewing new articles
• Publishing new articles

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

When a new article is ready for review, a publisher might check for:

• 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).

Here are some things to keep in mind for publishing new 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.

This section covers the following topics:

• Routing tickets for flagged articles
• Reviewing and updating flagged articles
• Solving tickets for 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.