Blog Post

Developer Blog
5 MIN READ

How We Built the KB Audit Flow Pt. 1

RyanPi's avatar
RyanPi
Khoros Staff
4 years ago

 

Trust in the accuracy of your Knowledge Base articles is essential to building trust and confidence between your visitors and the content they're interacting with within your knowledge base.

One way of ensuring that each KB article is current and accurate is frequent and routine audits on that content. The audit process should be straightforward for your authors, administrators, and moderators, and transparent for your readers.

To make this process as seamless and easy as possible on Khoros Atlas, we created an auditing solution that enables members with the appropriate permissions to set the article as "audited" and to display the date and time of the last audit to visitors.

In this three-part series, we're going to take a detailed look at how we built out this auditing solution in Khoros Atlas.

We highly recommend reading the next two posts in this series to get a better understanding of the other components and prerequisites required for this component to function properly.

Concept

Our 'Last Reviewed' component enables members with the appropriate roles (defined in the 'Last Reviewed' component we will create in this guide series) to see a checkbox in the sidebar of each KB article enabling them to indicate that the article has been audited. This "Audited" checkbox. When the box is checked, the time and date are saved as part of the audit trail.

Note: The role(s) required to see the Audited checkbox are set within the "Last Reviewed" information component we will create in the second part of this blog series.

Once that data has been saved, it is then displayed in the sidebar. This enables visitors to see when the article was last reviewed. This enables them to gauge how up-to-date the information in the KB article is.

Member Flow

 For permissioned members, auditing an article is as simple as reviewing it on the front end and selecting the Audited checkbox.

 Once done, a confirmation message appears enabling the member to confirm the audited state by selecting Yes, or cancel it by selecting No.

 Once confirmed, the date and time data is saved and that date and time become the new "Last Reviewed" date displayed to all visitors in the sidebar.

Prerequisites

Before this functionality can be added to the Khoros Communities instance, we need to make a few changes on the back end to create a space where metadata containing the audit timestamps and status for each message will exist.

This requires a few steps that Support can assist you with. To get your instance ready to work with the Audit Flow, simply submit a support request using the Case Portal and request that your Communities instance be configured to support Audit Flow.

Case Study: Khoros Information Experience Team

Our Product Content Experience Team is responsible for writing and maintaining the knowledge base (KB) articles for Care, Community, Marketing, CX Insights, and Khoros Flow. This includes a library of hundreds of articles, each focused on information that evolves alongside the products.

The Challenge

As you could imagine, keeping all of this content updated is a huge responsibility. Outdated information in our knowledge base leads to confusion and wasted time. We needed a solution that accomplished the following:

  • Instill confidence in visitors that the article they're reading is updated and accurate
  • Enable team members to record their audit of existing KB articles from the front end
  • Provide a visible label on each audited article with the time and date of last review
  • Create a process for determining which articles should be prioritized for audit
  • Execute audits in coordination with internal engineering and product teams

The Technical Project

To reach these goals, we partnered with the Atlas team, as well as our internal engineering and product partners, to create both a technical solution and team workflow.

The technical side of the project required some development work on Atlas. This included:

  • A new table in the database to store the "last reviewed" information
  • Metadata fields to represent the information in each article
  • A component that enables the frontend audit checkbox for users with specific roles
  • A component that displayed the "last reviewed date" of each article to all visitors

With these additions in place, our team members with the Administrator or Documentation role can mark a KB article as audited from the front end, and have the date and time of that review displayed to all visitors, regardless of their assigned role(s).

This accomplished the feat of both simplifying the review process and making a functional improvement that our visitors can benefit from.

Tackling the Audit Process

The next thing we needed to achieve was the active auditing of over 1,000 TKB articles currently in Khoros' knowledge base. Many of these articles were written years ago, and our team (at the time) was very small.

We partnered with various teams across Khoros to assign articles to subject matter experts, so it wasn't just our content team that was reviewing content. If the content was 100% accurate, it would be marked as audited. If not, we created a ticket in Jira and assigned a content team member to update it. This cross-functional auditing pass enabled us to audit ⅓ of the KB articles in our library in six months.

This approach brought with it a number of challenges. It was a logistical feat to coordinate with all of the teams and ensure deadlines were met. Additionally, we weren't entirely sure that every article receiving the bulk of our focus was actually being used by our customers.

So, we adjusted our approach for the second phase of our audit. Instead of tackling the entire library of articles at once, we instead focused on the following articles:

  • Articles with the highest average views per day
  • Articles with an average of at least one view per day since it was published

This was accomplished by examining the publishing date of each article, as well as its total views.

With this information, we could determine the average number of views for each day since the article was published.

Articles with the most average views per day received the highest priority. The rest of the articles with at least one visit per day would receive an audit once the first batch of articles is complete.

Now that our team has grown, we are able to set achievable goals and divide the work amongst our writing staff so that our efforts are targeted so each audit has the maximum possible impact on our overall customer experience.

Updated 4 years ago
Version 2.0

1 Comment

  • This is simple but brilliant (and would make so much sense to get productized) 👏 Very often when trying to convince other teams to use Khoros Knowledge base in the past three points against it were brought up:

    1. Review and publishing flow (Tackled in the recent content workflow update)
    2. Audit and update check capabilities
    3. Localization and versioning

    So with the audit feature there's only one more blocker left to move out of the way 😀