Knowledge Capture Publishing Workflow

Roles and Responsibilities

1. We do 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.

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

Creation & publish workflow

To create:

We use two templates to create articles:

For technical articles:

• Symptom
• Cause
• Resolution

For how-to articles:

• Question
• Answer

All the new articles are going to "Knowledge Triage" section and corresponding tickets are routed to an "Approvers" group by a trigger.

To publish:

1 hour per shift approvers have to spend working with tickets from Approvers group (separate view for agents). When articles reviewed, they put it into "Publishers" group.

1 hours per shift approvers have to spend working with tickets from Publisher group. When the article is published, KCS ticket is solved.

To flag:

Articles that are located in Knowledge Triage section (DRAFTs) have to be fixed by engineers asap, without flagging.

Articles that are located in Public section have to be fixed by publishers asap, without flagging. 

In case not a publisher works with a Public article, he has to "flag" it and write in a comment what needs to be fixed. In that case, the ticket is routed by triggers to Publishers group for review.

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 them.RQI 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, we are tracking article backlog (is it growing or reducing) and KCS activity per engineer.