Should Not Validated Articles Be Visible Externally?

We often talk about how customers want to know what we in support know, as soon as we know it.  Publishing knowledge to requestors quickly is one of the benefits of having responders create knowledge in the workflow!  However, we recently got a question about how that plays out in practice.  Should we really publish Not Validated articles externally?  Are there companies who are currently doing that?

There are a couple of examples in which companies have granted visibility to Not Validated articles externally.  As with much in the KCS methodology, judgment (and sometimes experimentation) is required.

  1. One software company we know of has a Quick Publish template, which is essentially a “breaking news” article.  It displays a Not Validated status and many disclaimers about “use at your own risk.”  They used it when they had an emerging issue that was impacting or could impact some determined number of customers.  Customers could subscribe for updates to the article for when a fix had been found/validated.  This allowed the company to do some proactive communication about known/emerging issues which freed up support resources to work on that issue instead of taking multiple calls about it.
  2. A variation on this theme are companies who publish problem articles on bugs found.  These articles include all of the required fields, but the Solution field displays the bug number and its status. Customers can subscribe to the article to get notifications on bug status, as well as any available workarounds. In this scenario, an integration with Jira or an equivalent bug tool to either automatically update the article, or automatically provide an article comment to the author with bug status change is key. This type of workflow prevents many cases being created for known bugs.
  3. Another company, who has a very technically-savvy user community, publishes articles in a Not Validated status for the same “we’re working on it” reasons. In addition, they know from experience that their users want to know as much as possible about an issue, as soon as possible – because often their users can act on it.

On the other hand, we’ve also heard stories of companies who have given customers visibility to Not Validated articles and then revoked that visibility – because those articles were driving more volume to support from customers who were looking for a Validated answer – they didn’t trust (or couldn’t act on) a Not Validated article.  

Yet another variation on this are organizations who work with external partners or third parties and use article audience settings to give visibility to Not Validated articles to just the audience who would benefit from knowing as soon as possible, or those who have a better chance of being successful with that information.

As always, we’re trying to create articles that are findable and usable by an intended audience; often that’s MUCH easier said than done!  While we advocate for designing for the most capable and then managing the exceptions, it takes some thoughtfulness about what knowledge to expose to which audience when.  

2 thoughts on “Should Not Validated Articles Be Visible Externally?

  1. I love this topic! Way back in the day, I think Progress Software was a pioneer in this area: https://www.serviceinnovation.org/included/docs/kcs_cs_progress.pdf

    I think this blog implies that it’s possible to have something that is both a Work in Progress *and* Validated. For example, the bug articles in your number 2 could be considered “Validated,” in the sense that the bug has been carefully identified and perhaps reproduced by engineering. But they’re also WIP, because there is no resolution, and perhaps not even a workaround. This is making me reconsider, slightly, the KCS v6 Article states.

    A proposal:
    – Audience (unchanged)
    – Governance (unchanged)
    – Publication Status (new): Draft, Published, Archived, with Draft being a very transient state
    – Confidence (lightly modified): Not Validated, Validated
    – Work in Progress (new): yes / no toggle
    – Internal Only (new): yes / no toggle

    The point of the Internal Only is that it lets contributors say “really, never share this with customers” in a way that Audience doesn’t…Audience may be only Internal because it wasn’t written by a Publisher, but that doesn’t mean it won’t be public someday soon.

    I know six axes sound more complex than three, but I think they map pretty well to many tool capabilities and implementations, and allow for some of the interesting and innovative ideas you’re poking at here.

  2. And internal/external isn’t even black and white.

    Those companies — especially those that have “a very technically-savvy user community” — are probably already seeing their customers post relevant info on such issues/bugs … getting their first-hand (though more anecdotal and certainly Not Validated) knowledge out there externally, often more quickly than the service team. The audience consuming such customer-generated knowledge tends to have has their expectations set about the validity, potential effectiveness, and risk of such info, taking into consideration the experience, trust level, ranking, etc. of the author.

    The folks publishing knowledge are ideally taking customer-generated content into account as well, both leveraging and being cautious of it, as they work to validate and publish definitive resolutions, which the bulk of affected customers will be eager to consume.

Leave a Reply

Your email address will not be published. Required fields are marked *