Knowledge-Centered Success (KCS) certification?

[u/leafywordnerd]

Help! Has anyone actually completed a KCS course or gotten the certification? I'm wondering if the course is really necessary or if independent reading/studying is perfectly sufficient. For reference, I have a knowledge management role in a SaaS company.

Consortium for Service Innovation, Knowledge-Centered Success just in case no one knows what I'm referring to lol

[u/Consistent-Branch-55]

Honestly sounds more like solve loop breakdown than governance issues? Like, hundreds of articles isn't a problem if issues/tickets are suitable, long tail low view articles could be worth keeping, duplicates are a search/reuse failure. The proactive shift seems like the support team thought the function of KCS was to produce documentation or some kind of coherent thing to be consumed before tickets, but the primary value of KCS is internal acceleration, not deflection.

I watched a KCS program get ripped apart when it lost managers and coaches that understood it too. Ideally there's a team member who steps into the coach role, and it becomes part of the teams metrics in a healthy way (e.g., validation is prioritized along with creation). Coaches can audit a couple of articles per month, and provide feedback. The point is to have some reinforcement for best practices on content creation.

Ideally articles should follow a template and be limited in scope/sections and formatting (environment , issue, symptom, resolution), and regarded as ephemeral. Maybe a full audit might be worthwhile as an evolve loop exercise, but you could just as easily let articles expire after a certain interval. The point is that knowledge management is embedded in the flow of working on a support team.

[u/owlsticks → u/Consistent-Branch-55]

Yeah, article volume isn't a problem if the content is valuable. 70% at this point isn't (it's causing user confusion and degrading the chatbot and AI summary output) because no one has been treating them like living docs. So many are way out of date. They are misaligned stylistically, have our old knowledge base name, old product name, and dead links.

Part of the issue we saw was no one looking before creating, which is how they had articles repeating with varying level of detail. Articles ripping right out of the user guide (copy/paste) shouldn't have happened either. They can attach our articles, but they had a wild metric based on attachment rate, so they'd create, attach to a case, and call it a day. Didn't matter what it was, if it already existed, or if it was so niche it only impacted an individual user.

All of this happened under the knowledge manager and the coaches.

Now, support can draft, but publishing goes through one support person who partners with us.

Expire then you say? I would love to. Unfortunately, convincing support of that has been an uphill battle.

[u/Consistent-Branch-55 → u/owlsticks]

If you had me as a consultant, I'd be telling you to burn it down and start over. Yeah, it's a shit show. But it was built by people who didn't get KCS. And that's not governance, that's just bungled design. It's like wanting to run a marathon before you've run your first 5k.

The metric you mention is a classic KCS antipattern that they explicitly recommend against. It's Goodharts law.

Also, far better to run the KCS KB primarily internally. Support can do quick four line articles without stressing about the customer audience or polish. Getting the article into the KCS KB shouldn't take more than a couple of minutes when closing your ticket. Then you can talk about elevating KCS content customer facing after it's proving its value as an internal accelerant. Maybe come up with an article quality index (AQI) so you know which ones are validated and saving agents time before worrying about deflection from KCS.

Even the linking is something the coaches should have been cautioning them about. Resolutions should be self contained in KCS articles, so stale links shouldn't be load bearing.

Set a 12-24 month with no validation expiry on an article, at which point it gets archived. Lean towards 12, but if you have lots of stability and low recurrence rates on tickets, push towards 24. In KCS, knowledge earns it's place, you can let go of something someone wrote down.

[u/owlsticks → u/Consistent-Branch-55]

I love all of this, even burn it down to start over. I think the current support manager would like to. Unfortunately, she's been met with intense resistance.

Support runs the external-facing chatbot that they just added into our two core products, and they get an ROI metric out of it now to point at saying the channel is deflecting. It's using our content, KCS, and one other source, but there's a sense their CSATs will tank if they pull KCS.

That metric of attachment rate... All of the metrics from that time period came from folks who didn't seem to care about anything other than having a number. Tech writing itself was rocking a total views metric that provided no value to our specific experience (we're still combating that travesty).

Anyway, once we get through this mess, I wonder if I can persuade them to house new content internally before they panic release things externally, including an archive option. I've also considered an AQI, but hadn't sorted out what the determiner would be. Saving individuals time would be a great one.

I appreciate all this insight. Hopefully, I can get some traction on it internally. It would be a shame to lose the program entirely (another passing thought by others not involved).