Recent searches
No recent searches
Knowledge Capture Publishing Workflow
Posted Aug 24, 2017
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.
0
5 comments
Jennifer Rowe
Anton, this is great! Thanks for sharing details about your workflow!
0
Dan Cooper
This is a great workflow and your metrics are awesome. We did a stint with comments on the article being the “flag” for a bit. We had a slower turnaround on fixing articles then, so we told our team to review comments too for potential flags they should consider. When we fixed the flag, we’d delete the comment.
0
Deepa Daniels
Wow, thank you for sharing Andrew!
0
Grego Malone
Thanks for sharing your workflow, Anton.
I gotta ask though, how do you track relations between articles and tickets?
Currently, there's no way neither in Insights nor in GoodData reports to easily see which articles have been linked to a ticket when you open it. Or vice versa, when one opens an article and sees all the tickets that have been attached to it. In other words, what tools do you use to properly track KCS reuse?
And how do you then make decisions on choosing which articles should be left as DRAFTS for further reuse and refinement, and which ones should be published?
0
Brett Bowser
Hey Grego,
While I can't speak to Anton's workflow, have you had a chance to look into the Content Cues feature available on Guide Enterprise? Content Cues uses machine learning technology and Guide article usage data to help you discover opportunities and tasks that will improve your knowledge base health.
This may not be the exact solution you're looking for but maybe worth digging into.
0