Setting Up your Knowledge Base
- Define your community Topology
- Setting up your permissions and moderation
- Setting up a Designated Area for Internal Collaboration
- Analytics and Reporting Preparation
- Identifying New Knowledge Base Articles
- Creating Knowledge Base Articles
Maintaining the Knowledge Base
- The Continuous Article Review Cycle
- Identifying the Most Active Articles
- Identifying the Least Helpful Articles
- Determining Whether an Article is Permanent or Temporary
- Flagging items for review
- Knowledge Base Engagement
Measuring Success of your Knowledge Base
- Define Your Success Metrics
- Guest access to the Knowledge Base
- Setting up Google Analytics
- Building Google Analytics User Path Flow Sequences to Track KB Success
- Sample Sequences to measure KB Success
- Gathering metrics from your User Flow sequences
- Gathering Metrics from Community Manager Reports (CMR)
- Formatting and presenting your KB Metrics
Jive has the experience to guide you through the KB life cycle and the necessary steps for running a successful customer knowledge base community using Jive. The materials in this guide are designed to outline a series of best practices and recommendations for planning, deploying, and managing a knowledge base, with the end goal of measuring direct ROI and impact on your support organization.
This guide walks community managers through six separate phases of implementing a knowledge base:
- Setting Up your Knowledge Base
- Identifying New Knowledge Base Articles
- Creating Knowledge Base Articles
- Maintaining the Knowledge Base
- Knowledge Base Engagement
- Measuring Success of your Knowledge Base
Setting Up your Knowledge Base
The right structural foundation is essential for KB success. The following topics should be considered as you design and set up your KB community in Jive:
- Community Topology
- Creating the KB place
- KB Content Templates
- KB Category and Tag Best Practices
- Creating a KB Overview Page
- Configuring KB Permissions
- Reporting and Analytics Preparation
Define your community Topology
Space Hierarchy in Jive
As you begin to set up and plan the deployment your knowledge base, one of the initial items you will need to consider is where the knowledge base will live within your community structure and your established site hierarchy.
Your knowledge base area will be a dedicated place within your existing Jive community structure.
The goal for this section is place your knowledge base in an area in your community that is consistent with the rest of your site layout and is organized in a way that meets your customer's expectations and is optimized for their needs.
Creating a cohesive community taxonomy and sitemap that is tailored to your customer's needs is much broader topic that is not covered in this knowledge base guide. It is recommended that you work with a strategy and planning team in order to define the community structure that will work best for your organization - Determining where the knowledge base lives within your community is one piece of this larger conversation.
Although the purpose of this section not to provide a complete outline of how to structure your Jive community, there are several common patterns that have been established that your community may follow. You can use these examples to get a sense of different options for how the knowledge base may be placed within the larger community structure.
It is common to see that your organization will interact with your community members through either Product venues or through Function venues. If you are using Jive to cover a series of Products, which have a variety of Functions, then you will need to determine whether your Top Level Space hierarchy will be comprised of your Products or your Functions. Below you will see select examples of communities organized by either Products or Functions, and how these related to the placement of your knowledge base area.
Method A - Top Level by Products
- Top Level Spaces by Products
- Secondary Level Spaces by Functions
This structure is ideal if your Jive community's primary function is one of a support community. If customers go to your site with the intention of looking for support materials, then it is advised that the top level if your hierarchy is comprised of your various products or services. This also may be a viable structure if you're providing B2C services. You may also find this to be a natural fit if your community is focused on Technology, Software, Clothing, Electronics, or other goods.
Having products as your top level hierarchy will also work best if you organization is focused on a range of products that have little overlap regarding support, sales or marketing materials.
Your Knowledge Base and Support spaces will be considered 'Functions' of each unique product and will live under the products in the hierarchy.
Example: Virtucon Support Community
Hierarchy Type: Method A - Products > Functions
Method B - Top Level by Function
- Top Level Spaces by Functions
- Secondary Level Spaces by Products
This method is ideal if your Jive community is used for a variety of purposes beyond just support.
If the community is used by marketing, product management, and developers, then organizing content by function is a common approach.
Organizing your community by function will also be ideal if your organization's offerings are tied to a select few products, or if you have a single primary product with a selection of secondary products.
If your organization is focused on B2B services then you may find that this structure is applicable to your community. You may also find this to be a natural fit if your organization is focused on Services, Telecommunications, Health Care, & Financial Services.
This is also a viable approach if you are utilizing your Jive instance and support community where end users will be reaching out and communicating with only a specific group of users who are subject matter experts, as this allows for the expert to be involved in a variety of places that span a range of contexts. This is a recommended layout if your customers need to first start with a type of support as opposed to product based. For example, for a telecommuniations organization, the top level function may be Account Management, Billing, Upgrades, Devices, and Business Services. Additionally, if you have a large demographic of users who are involved in a custom development, you may use functions as your top level spaces, with one of the places being the Developer Community.
ACME Organization Community
Hierarchy Type: Method B - Functions > Products
Method C - Hybrid
- Top Level Spaces include both Functions and Products
This approach is a mixture of the two previous methods. The focus here is to highlight both key products and functions in the top level of your community hierarchy. This is recommended if you have a select few products and you also have several popular functions that are not directly related to those products, or the functions share a 100% overlap across all products.
This is also a viable option if you have a new community that is being set up and the size of your organization and its products & services do not warrant a the overhead that comes with having a uniform space hierarchy.
This is the most flexible structure, but it can become harder to maintain as your organization grows and your products and services change over time.
Example: Oceanic Auto Community
Hierarchy Type: Method C - Hybrid
Deploying the KB Space
During the deployment, if you're handling both Peer to Peer discussions and KB Articles in your Jive Community, then you will need to decide whether or not you're going to combine both of these support services into a single space, or if you will separate these out into two different places.
It is recommended that you hold your Peer to Peer support discussions and your KB articles in a single space for the primary reason that it provides a single place for your customers to go to in order to find support resources. If they are separated out then you run the risk of losing a portion of your audience that is only exposed to one space and not the other. Merging a knowledge base and a peer to peer discussion place into a single space will require that you lock down your permissions to the point where only the support team is capable of creating new documents.
If you have a previously established peer to peer support community and you're not able to easily change the permissions in the space then it may be appropriate to create a separate KB space that only holds your KB articles. Although this is less than ideal, it does provide a clear separation for your customers around where they can expect to find community generated answers and where they can find materials published by your support organization.
In order to maintain a consistent and predictable knowledge base article format it is a best practice to create a series of document templates that can be reused for most of the content that will be created. The template will define a standard set of headers, sub-section titles and hierarchy for these headers. A secondary goal in using templates is to minimize the amount of time required for the content author to start writing new material, and enable the author a structure to format their content. Using a template will also serve the purpose of reminding the content author of providing information related to the article that may not have been originally considered. If a template section exists but the author does not believe there is any value in including it in the article then the section may not be used. The number of templates used will be dictated by analyzing existing and planned knowledge base materials and finding commonalities between the types of content that is being published. It is expected that most knowledge base articles can be formatted within a standard template, although there may be exceptions for specialized articles that have a unique format. Each template will be its own unique Jive Document, and will be the basis for nearly all new knowledge base articles.
Example Types of Templates
- Frequently Asked Questions
- Technical How To
- Feature Documentation
- Issue Workaround
For example, the Issue Workaround template may use the following sections:
- Issue Details
- Bug ID
- Bug Summary
- Affected Versions
- Fixed in Version:
- Identifying the Problem
- Related Materials
Tagging Knowledge Base Articles
The primary purpose of tagging KB content is to increase the searchability of your published content. It is assumed that a significant portion of the traffic to the knowledge base will be through customers searching with terms around their issue, so it is critical that your content is written in such a way that it is easy to find via Jive's built in search services. As with article title, it is important that all of the unique search terms customers may be using to find your content are included in the set of tags.
For example, if the document "How to reset encryption keys" had one tag of "#encryption keys", then it would match the search query of "node.id encryption key reset" but it would typically be ranked much lower than if the tags were instead "#node.id" and "#encryption". It is paramount that your title, content, and tags all include as many keywords as possible that you believe your customers will be using to find your content.
Tags are a helpful way for you to include certain phrases or words that customers may use to find your content, but may not be actually relevant to the published content. For example, your users may refer to a feature by using an informal word unofficial terminology that is not in your official documentation - Adding these informal words to the list of tags is a great way to increasing searching relevance.
Categories allow your KB management team to organize the KB content into predefined groupings of content. The KB manager will need to define and configure a set list of categories to be used only in the knowledge base space. When a new KB article is being published, the author has the option of adding the content to one of the defined categories. Categories can also be thought of as "buckets" or different types of "use cases" for your KB. A key difference between tags and categories is that categories must be defined for only the KB space and are consistent across all content in the KB place, while there are no restrictions around the types of tags, or the number of tags you may add to a document. Tags also apply to the entire Jive community, while categories are specific to your KB place. While tags are used for increasing discoverability and searchability, categories are used to enable content filtering through structured units. Categories can also be thought of as various folders where your content can be filed into. Examples of categories may be:
- Best Practices
- Frequently Asked Questions
- Issue Workarounds
- Troubleshooting Guides
- Feature X
- Feature Y
- Feature Z
A best practice is that a single KB article should not be in more than 2 categories at one time. If you are finding that an article could be assigned to 3 or more categories, then you may want to consider breaking up your article into a set of sub-articles that focus on different use cases, or you may want to alter your category list so that your categories have clear purposes.
Creating the Knowledge Base Space Overview Page
Designing the visual layout and hierarchy of an overview page is a critical part to successfully deploying your KB and putting a face to your portal. There are several key functional widgets available in Jive that are recommended for use in the KB overview page, prioritized by importance:
- Search widget
- Recent Content
- Featured Content
- Popular Content
- Popular Tags
Primary widgets should be the search widget, recent content, and featured content. The goal here is that all of the focus is placed on the KB content and allowing users to find the most relevant and latest content related to their questions.
The Recent Activity widget has been omitted here as the main focus of the knowledge base is turned towards content and articles, and not necessarily the latest customer created comments. There is an acknowledged value in peer to peer discussions in the comments of a KB article, but this is not the primary reason for a person going to the knowledge base.
The overview page should also make use of a formatted text or HTML widget that serves as a summary for the knowledge base, and a clear call to action on how to use the KB. It is important to highlight various verbs in this call to action, such as Search or Navigate, so that it is clear to users how they should be interacting with the place.
Setting up your permissions and moderation
Permissions in Jive are a powerful administrative tool that let you control who can do what in a given Space. In this Set Up phase of your Knowledge Base, we recommend you assess your immediate and long term goals. It normally makes sense to limit permissions initially to your internal teams who will create, publish, and manage the knowledge.
With that said, a common consideration for the future is allowing your top contributors (i.e. non-employees) to create or collaborate on KB content. This topic is discussed in the Community created KB Articles section.
The reasoning here is that your organization is responsible for all published content, so it is imperative that only members of your team are able to publish new KB materials that have been reviewed and approved by the KB management team.
Allowing Guest Access
Jive recommends that your Knowledge Base should be publicly accessible, available to all users and search engines. Having invested in the creation and maintenance of all your content, you want to reach the broadest audience possible. Unregistered users should be able to find and use the knowledge and access should not require logging in. Making the KB content public will improve your SEO and provide insight as to how your content is being found from outside of the community itself.
There are two challenges to publicly accessible KB content. First, it may benefit users who are not your customers. For example, an article may be published that covers troubleshooting a tool that is not specific to your product - An article may be used by folks who are not using your product and found the content through an unrelated Google search. Second, Jive's CMR reporting does not currently distinguish activity by anonymous users, so registered and unregistered user activities are combined in the reporting data.
Still, experience suggests that the benefits outweigh the challenges, and we strongly recommend public access because it will ultimately provide more answers and result in more deflected cases.
Example permission setup
In this example, we are allowing Guest access to read all KB content. We have also set up two permission groups to allow the Support Team to create new content and another group that is responsible for moderating this content. This allows new content to be created by anyone at the organization, but it still must be reviewed by a select few individuals who are responsible for the KB.
Setting up a Designated Area for Internal Collaboration
As the KB team begins to produce new KB articles you will need to set up a designated area where these KB drafts can be created and worked on by your team prior to them being completed, approved, and published.
There are several important reasons for having a separate, designated area where your team can freely collaborate on KB drafts:
- There is clear designation between content that is published and content that is not yet customer accessible
- KB authors can easily collaborate on content with technical staff and subject matter experts who do not want to be exposed directly to customers
- Comments and discussion can happen on KB drafts without concern of customer sensitive information being accidentally published or released
The general recommendation is that you have a KB Drafts area, where articles are collaborated on with various members of your organization, and upon the content being approved, the KB team will take this content and publish it to the official KB place. This set up can be implemented either in a single external instance of Jive, or can be broken out across two different Jive instances: One Jive instance for internal collaboration, and another for the externally published KB materials.
One External Instance of Jive
Your team will create a second private space in your external community, and set up the permissions so that it is only accessible to employees of your organization.
The team will create all new KB drafts in this area and work with various subject matter experts in this place. When your team has a new article that is ready to be published, the knowledge base manager has one of two ways of doing this:
- Move the document from the secret place to the external knowledge base area in Jive.
- Copy the content into a new document in the KB place
The knowledge base manager must be sure to verify that the correct categories are selected during this moving or copying process. It will also be important to delete any comments on the document that are not appropriate for customers to see.
A potential downside of the moving method is that any previous versions of this article will be accessible to customers, so be mindful of including any sensitive information in early drafts of the document. If this is a concern, it is recommended to use option 2, where you copy the content, so that the version history is not carried over into the published document.
Two Separate Jive Instances: Internal and External
One possible KB implementation is to first create the new articles in an internal Jive instance, where support analysts can freely collaborate on documents with various internal experts, and when the materials have been reviewed and approved for publication, the knowledge base manager will go through the following steps:
- Create a new document in the External Jive instance
- Copy the title, body, tags from the Internal Jive document to the new External Jive document
- Publish document
- Update the internal document to reference the external document
Once the article has been published the knowledge base manager will need to update the internal document in one of two ways:
- Delete the internal document to avoid duplication of content and ensure that there is a single source of truth for support materials
- This is most often recommended - Especially in scenarios where the KB content is a collection of other materials already available within your organization.
- Publish the internal document to a separate internal knowledge base space and include a reference link to the external version.
- This is only advised if your team has a separate knowledge base area, and the article itself is original content not found anywhere else in your internal community.
Analytics and Reporting Preparation
For setting up Google Analytics, it is recommended that you review the Analytics Setup section before you launch your community.
Additionally, this initial set up phase is the best time to begin thinking about how to define success success for your KB and the various metrics you will use to measure success. More details on this topic are discussed in the Define Your Success Metrics section.
This guide also recommends using Jive's Resonata reporting tool for content analysis - There is no preparation needed in this phase for later deploying Resonata.
Identifying New Knowledge Base Articles
Topics for new KB Articles can be identified in a variety ways and a set of recommendations are below.
Note that the methods detailed below evolve from simpler, human-generated concepts to increasingly complex analyses or feedback employing a variety of tools. The initial methods rely more heavily on your existing subject matter experts and allow you to start identifying content immediately. As your Knowledge Base evolves we do recommend the additional methods as appropriate.
Support Team Solicitation
One approach for gathering ideas for new KB articles is through members of the KB team proactively reaching out to support staff and soliciting input around what topics the team is seeing as repeat issues or problems that can be addressed through the existence of a KB article.
Solicitation can be done through face to face team meetings, blog posts, or by reaching out individually to members of the support team.
High Impact Bugs and Issues
If you are supporting a software solution, then using your bug tracking system can be a great way to identify either issues that are impacting multiple customers or high severity issues that you need to get out of front of customers as soon as possible.
There are two reports you should run against your bug tracking software to identify possible KB articles to produce:
- Bugs that are associated with a high number of reported incidents
- Please note, this is only possible if you have integrated your case tracking system with your bug tracking system in such a way that you're able to report on how many times a specific bug has been reported by or impacted a customer.
- Bugs that are high severity and have been recently opened or resolved
You will need to consider your organization's case volume, bug creation rate, and bug closure rate when defining what is considered a "high number of reported incidents", as well as how far back in history you will go when looking up recently opened or resolved issues. These thresholds will also vary based on the size of your knowledge base team and the rate of new KB content being produced.
It is also critical that you're focusing on issues where your KB content will be presented with one of the following two purposes:
- Issue workaround
- Issue acknowledgement ( no workaround available at this time)
Most of these types of articles will be written about known bugs, some of which may already be fixed in later versions of your product by the time the knowledge base article is published. Typically these types of articles that are specific to known issues are most valuable the moment they are published, and over time, as new versions are released and customers upgrade to these versions, the value of the article will lower as fewer customers find themselves impacted by the issue. Due to the diminishing returns of these types of articles, it is important that you're able to publish these articles as soon as possible.
KB Nomination Flagging
The team that manages your support tickets and answering customer questions is going to be a valuable resource for determining what KB articles should be produced in order to deflect new cases being created by customers. This team is directly exposed to the issues that customers are facing, and they will have first hand experience with helping identify the different types of issues that would be best served by the knowledge base. The recommendation here is that you enable this support staff in being able to quickly identify support case issues that serve one of two purposes:
- This support case can be used as a basis for a new KB article
- This support case could have been resolved or deflected if a KB article existed
The goal here is that you are able to modify your case management solution so that your support staff has a quick way of flagging support cases as being KB Candidates. This KB nomination process should be one of your primary sources of new KB articles, as your support staff is going to be the best source of knowing what issues would be best addressed by the presence of a KB article, and the team is also incentivized to see KB articles being created, as it means that the team spends less time working on repeat issues and it enables customers to proactively resolve issues before reaching out to support.
Once the support staff is trained on nominating cases as being KB candidates, then the KB manager will be responsible for regularly reviewing these KB nomination requests and will begin tracking and prioritizing accepted KB nominations in a tracking system.
This change must be implemented in the system that your team uses to manage support cases. This is a built in feature of Jive's CRM Connector with Salesforce. In this scenario, support agents are managing support cases in Salesforce, and they are able to flag these support cases as content that should be turned into a KB article.
Community KB Article Requests
Similar to the process outlined earlier, where support representatives can nominate support cases that should be turned into KB articles, another source of new KB materials can be through customers and end users requesting specific KB articles.
Typically when a customer requests information it will already be done through a support case, but it is a possible to offer an alternative path. You can enable the "Ideas" content type in your KB space, and then allow registered users to create new Ideas for new KB articles. It is then recommended to create a widget in the KB overview page layout that specifically calls out that customers can create new ideas for new KB articles. You can use the following text as a starting point for your call to action.
Can't find what you're looking for? Create a new Idea and request a new KB article.
Using Resonata to Identify Common Themes
Jive's Resonata tool analyzes the activity in your Jive community and reveals the sentiments, behaviors and motivations that drive participation and satisfaction. You can identify your community champions and detractors, track trends and spot emerging problems.
The main focus for building out a KB will be using Resonata to identify emerging problems and common themes in your community.
To start gathering this information, we recommend you build a new search report that covers your existing support discussions in Jive, and excludes content created by your employees
- Date is in the last 6 months
- People do not have labels: <Support Team>
- You will need to set a label that includes all of the support team members whose content you do not want included in the report. We are only interested in parsing content created by customers.
Setting up people labels
In order to set up the second rule, where you filter out content from a group of users, such as your "Support Team", you will need to assign labels to your various support staff members who are contributing content to your Jive community. You can do this by running a report for your community, scrolling down to the People section, and opening the profile panel of various members of your team. You can then update their profile in Resonata to include any label you like.
We recommend you create a single label for all support members who you wish to filter out of your Resonata reports. There may be secondary reports you run on specific sub-teams within your support organization - If that is the case then it is suggested that you add multiple labels to the profile.
With this report configuration you will be able to see the following pieces of information that are relevant to identifying new KB articles to produce:
- Common Themes and Phrases
- People with most posts
- Sentiment trends
Gather the themes and begin using this a way to identify what key terms and areas in your community are generating the most content.
It is also recommended that you re-run the same search but filter for only negative sentiment and then review the updated list of themes. It will be good to compare this new list to the previous one to get a sense of what discussion topics result in a negative experience for customers. You may also discover that one of your top initiatives isn't necessarily associated with negative sentiment - In this scenario you may want to analyze why this may be. Could this particular topic have a positive sentiment due to more available documentation? Is it due to a software feature being more matured?
Search Text Analysis
An additional way of understanding where your knowledge base may need to have additional or improved content is through the process of analyzing the search terms that are being used to find content in your Jive community.
Using Jive's Data Export Service, which is powered by Jive's Cloud Analytics services, you are able to access and export analytics data that is generated by your Jive community. This is available in Jive 7 and Jive Cloud.
You can read more about how the Jive Data Export Service (DES) works by reviewing this document: Using the Jive Data Export (Analytics) Service | Jive Community
In this example, we are interested in exporting a list of previous search terms used in the community. You can easily do this by generating a report that filters the analytics data by the action called ACTIVITY_CONTENT_OR_PLACES_SEARCH. The Data Export Service lets us generate content using either an API end point or using a web UI at API Explorer
Data Export Explorer UI
You will want to generate a report using the following settings at API Explorer
Data Export API
If you are using the Data Export API to access analytics data, then for this example you will want to run an API call like the one provided here:
Be sure to consult the materials at Using the Jive Data Export (Analytics) Service | Jive Community for additional information on how to further refine your analytics query to meet your needs.
Both of the Data Export methods listed above will result in a CSV file that you can then use to start parse search text strings. The CSV will come with a variety of columns worth of data - The column ContentActionObject.Keywords will hold the search terms used by your users on your Jive site.
Types of search
In Jive there are two ways users can be searching for content. Users can either search for content using the Spotlight Search Menu or the Main Search Page. Searches performed in the Spotlight Search Menu will always end in an asterisk (*) character. Searches initiated in the Main Search Page will not have the asterisk character.
This is a helpful way for determining the source of the search term, and can also explain why you will sometimes see reporting data like the following:
|How to setup backups|
|How to setup backups*|
|How to setup back*|
|How to setup*|
By default the reporting data is sorted by the latest search terms at the top. Here we can see that when we look at the bottom of the report, a user is using the spotlight search menu to initiate a new search, and as they begin typing in their search terms the spotlight tool is continuously gathering new search results to reflect the updated text the user is entering. The last search does not have an asterisk character, which means that the user initiated a Main Search with the terms. This can be if the user presses enter on their keyboard when typing into the Spotlight Search Menu.
Analyzing the Results
With the raw search query data, it is advised that you initially manually review the contents of the report and inspect the search terms by hand. This is helpful to spot specific examples of what people are searching for, as you may find some specific questions asked through the search service that you were not expecting.
After manually inspecting the list of search results, it is advised that you run the search terms through a text analyzer tool to discover the most common words and phrases customers are using to search for answers. In addition to this being a source for what type of content to produce, this will also give you a sense of what words to use in your article titles and tags.
Example from Jive Community
Creating Knowledge Base Articles
As your team identifies topics that are worth of writing new KB articles on, you will next need to produce new KB articles and have them published in the community. There are several components to the content creation phase:
- Establishing a consistent writing style and format
- Prioritizing and managing content
- Producing content
- Review and approval processes
- Publishing processes
Materials published in the knowledge base should exhibit a consistent and predictable writing style that has the following best practices:
- Easy to read and scan. One way to achieve this is to avoid large paragraphs that readers may skip and breakdown the content into bullet point lists.
- Optimize your writing and word usage for better searching and findability
- When embedding an image that has text relevant to the issue always write out the text in the document so that the material is searchable
- A written voice that matches branding guidelines of both the organization and the support team
- Proper use of formatting within the Rich Text Editor. Proper use of quote blocks, code syntax highlighting, header styles and table of contents
- Using a consistent Narrative point of view within articles and across all articles in the knowledge
- Second person vs Third person point of view
- Second person narrative may be best if you are seeking a more informal tone and speaking directly to the reader. The article is often written referencing the read as "you".
- Third person narrative relies on using "he", "she", "it", or "they", but never as "I" or "we" (first-person), or "you". This can result in written materials that are more formal and clinical.
- First person narrative should be avoided when creating a KB article. This is the recommended mode when replying to comments and managing community discussions.
Document title best practices
When creating a new KB article's title there are three properties to consider:
Readability: A general rule of thumb for creating a title is to keep titles less than 20 words. Anything longer than this will result in a title that is harder to scan and may result in users not reading the complete title.
Searchability: You will want to carefully choose the words you use in your KB article title so that it is both easy to understand and will be easy to find through Jive search. It is important to include key nouns in the title that are related to the issue, as this is likely to be what customers are searching for.
Memorable: Crafting an article title that is memorable is an element that can be overlooked, as it is harder to define what makes one title more memorable than another. The reason we want to make memorable articles is to increase the likelihood that a user is able to navigate back to an article that they previously looked at. It is not uncommon for users to continually reference past materials over a long period of time, and making memorable titles is a great way to ensure that users are able to quickly find these articles.
One way to do this is to occasionally use unusual or unique phrases or words in a title in order help have it stand out. For example, if you have a troubleshooting guide that is specific to leaderboards, you could try to use a title like "The Definitive Guide to Leaderboards". The word "definitive" may be unique and is a key way for users to latch onto an title and help them remember it for later retrieval. Another example is "Performance tuning from 10,000 ft". Using the term like "10,000 ft" is novel and unique, and also serves a secondary purpose of declaring that the article is a high level overview.
Prioritizing and Managing Content
You will need to put a system or method in place in order to manage and track all new KB content that the knowledge base team is responsible for. What system or method that is used is largely dependent on how large your KB management team is and the volume of KB materials that are being published.
If your KB team has 3 people or less, then it is expected that you will be able to manually manage and prioritize the production of KB content through a single Jive document, also known as a 'Tracking Document'.
If your KB team has more than 3 team members, then it is advised that you manage the KB production life cycle through an external ticketing system, such as Salesforce or JIRA. Additionally, a ticketing system will allow you to keep a record of all completed KB requests, which can enable you to report on your KB production. This is not something that would be feasible in a basic tracking document or spreadsheet. Lastly, if you are going to integrate features like a KB Nomination app into your case management system, where users can use a tool to suggest new articles to be written, it is advised you plan your KB production in a ticketing system, as this will allow you to directly integrate this feature into your KB production workflow.
The main purpose of using a tracking document or a ticketing system is so you have a single source of truth regarding the status of your upcoming KB articles.
The knowledge base manager will maintain a list of all upcoming KB content, which each record being in one of the following states:
- New Request
- Rejected Request
- In Progress
- Final Review
- Published / Closed
Please note, these are only recommended states for you to start with. Depending on how your team manages KB article requests, some of these may not be necessary, or you may have new states to add.
All KB content will start in the New Request state and progress through to the Published state.
As New Requests come in they will enter a Triage state, where the KB management will review these and either approve or Reject the requests. Once they are approved, they then go into an In Progress state, where the article is then assigned out and written. If the article is approved, but it will not be written at this time, then it will enter the Backlog status. If the article's production has started, but it must be paused because of other dependancies, like requiring a meeting with a team member, then the KB item will enter a Blocked status. Once an article is finished, it will then be assigned to another team member for Final Review. Once the reviewer has approved the item, the author will then Publish the content.
This tracking process can be achieved through a tracking document in Jive or a dedicated ticket tracking system - A tracking document in Jive has fewer restrictions and will work best with a small team who is often working face to face, while a ticketing system will be best for a larger team to ensure that all documents are progressing through the life cycle in a standardized way.
KB Tracking Document
If you are using a Jive document has your tracking process, then it is recommended to follow these best practices
- Each document should be ordered in the table based on their priority, with highest priority items higher in the list.
- Priority is determined by the following factors:
- How many customers may be impacted by the KB article
- If the doc is a bug workaround, how many customers are potentially affected? How many customers have reported the bug?
- How urgent or time sensitive is the document? Example, a bug workaround or a newly released version should be high priority due to the value of the content declining over time
- Each new document should be produced from top to bottom in the prioritized list
- As authors and reviewers are assigned to varous documents, @mention them in the table to signify ownership.
- As items move from state to state(e.g. New Request to In Progress), you will want to drag the row to the appropriate section in the table.
Example of a KB tracking document table
|How to configure the Document Creation page||Dustin Smith||Rachael Sims|
|Renaming headers in the Daily Updates email||Jeff Morgan||Chris Davis||http://www.mysite.com/docs/DOC-1002|
Additional notes from case here: Support case 303
|How to whitelist enhanced reporting for new customers||Lindsay Reid||Chris Davis||http://www.mysite.com/docs/DOC-1003|
|Impact Metrics FAQ||Chris Davis||http://www.mysite.com/docs/DOC-1005||Waiting on feedback from engineering before progressing.|
|How does Report Recommendations Work?||Bill Graham|
|Setting up your new ACME Tools Account||John Doe|
KB Ticketing System
If you do choose to implement your KB production life cycle in a separate ticket tracking system, instead of a Jive document, then you will need to make sure that the system is capable of allowing you to customize the status or phases of your tickets. Example systems where this can be done would be Salesforce, JIRA, or Redmine.
An additional benefit of using a dedicated ticketing system is that you can add custom fields for your KB requests, which you can then report on. See the list of custom fields you can use.
KB Request custom fields:
- KB Request source
- KB Request Priority
- Published Date
- Release sprint
- This may be helpful if you plan to release KB articles in specific sets or sprints instead of continuously over time.
- This may be helpful in tracking what version of your product the article was written for. You can report on this at a later date to find potentially out of date materials.
For producing and writing new KB articles, there are several phases the article will go through:
- Gather information relevant to the article from the following sources for writing content:
- Past Support cases
- Internal discussions and documents
- Bug reports
- Knowledge area experts within the organization (To extract Tribal knowledge)
- All new KB content will be first written in a new document in an internal Jive instance, where collaboration and comments can happen.
- Use one of the pre-existing template to format the article.
- The article may be written by either the knowledge base manager, a support rep, or a knowledge area expert outside of the support team
Use of templates
As defined earlier in this guide, your team will want to define a set of reusable templates that are applied to your documents, in order to give your content a consistent and predictable format that your customers will be familiar with.
Typically when you create a new document, you will want to first find the template that you are going to use as a start, and copy that template content into your new blank document.
Additionally, there may be an opportunity to develop a custom module so that when a new KB document is being created, the author is first presented the option of selecting which template to use. The new document will then be automatically populated with the content of the template. Using this type of customization would save the author time when creating new documents, which can also increase participation in the KB authoring process and enable users who would normally be discouraged from following a template.
Review and approval
Once the KB article is written, the KB manager, or the author, will assign an individual to be the reviewer and approver of the article. The reviewer will be responsible for checking the following things:
- KB Content is factually correct
- Content follows a predefined template
- Proper spelling, grammar, and writing style
- Relevant tags, categories
Once an item has been reviewed and approved, the author or KB manager will need to publish the internal draft to the external KB place. How this process is done depends on the structure of your KB and where your internal drafts are held. As defined in Setting up a Designated Area for Internal Collaboration , the process typically involves either Moving an existing document from one place to another, or creating a new document in the KB space and Copying over the content from the approved draft.
You will need to make sure that the following items are maintained during the publishing process:
- All content images & embedded videos
Community created KB Articles
There may be opportunities for community members and customers to create new KB articles that get promoted into the knowledge base. Customers may be able to contribute to the knowledge base based on their areas of expertise and experiences that are unique to their organization.
This is also an opportunity for customers to create new content that gets published and endorsed by your own support organization, which can give these customers, and their own organizations, exposure and recognition to other leaders in the support community.
It is recommended that the end user create a new document and add various support representatives to the document as contributors and work on the document in a draft state, and then the document can be published to the knowledge base space once it is completely reviewed and approved by all authors. This will allow the customer to create the document and retain publishing credits on the document once it is made live.
Maintaining the Knowledge Base
The purpose of this phase in the management of the knowledge base is to maintain the health of the existing content in the knowledge base. This phase is a continuous process that will take place during the entire time that the knowledge base is being actively managed.
The Continuous Article Review Cycle
The first method of ensuring the health of the existing content to deploy a process where the knowledge base management team will review and update all of the knowledge base materials on a regularly scheduled cycle. The goal here is that once a period, the team will do the following for each knowledge base article:
- Verify that the content is up to date given current support best practices and knowledge
- Verify that the content is updated to account for the latest released and supported versions
- Verify that there are no unanswered questions in the comments of the document
If the content is not up to date or there are unanswered questions in the comments, then the document should be added an internal tracking system that the KB management team uses to prioritize and assign out the work needed to update these materials. The repeating rate that the full suite of documents will be reviewed should be adjusted based on the following factors:
- Number of published documents
- Number of knowledge base management members
- Rate of new software releases
Managing the review
In order to manage the logistics of the regular review cycle, we recommend that you begin with a list of articles that are up for review and you work through the list throughout the review period. There are some different ways of generating and managing this list:
Method 1 - Manually Tracking Reviews in a List of Articles
The KB manager will export a complete list of documents from Jive, using the CMR, and and create a new KB Article Review Tracking Document. The document will have a table, with each row being a different article from the KB space. The internal tracking document should track the following data points for each knowledge base article in the table:
- Document Title
- Link to document
- Last review date
- Review Status
- Content Needs Updating
- Updated on YYYY-MM-DD by User Name
- Changes needed
- Comment replies
- Content out of date
- Content incorrect
Once a article has been reviewed and updated, the status of the record in the tracking document should be updated accordingly. All documents should be updated by the end of the review cycle.
Method 2 - Tracking reviews in a Ticketing System
In this method, instead of tracking the progress of the review process in a Jive tracking document, each KB article up for review will be entered as a new ticket in your internal ticket tracking system. If you are already using a ticket tracking system to manage the production of new KB articles, as defined in KB Ticketing System , then this method is recommended. Each ticket will be opened in an "New" state, and will be changed to a "Closed" status upon being reviewed and updated.
Method 3 - Automated reviewing via a Jive Customization
An alternative method for managing the review status of your KB articles is through the use of a potential Jive add-on or extension that would add a new feature to your Knowledge Base articles:
- The ability for a user to click a button on a document to set a "Last Reviewed" date for an individual document
- The ability to export a list of all documents in the KB space, with the "Last Reviewed" date as one of the data fields.
If you have this type of customization implemented, then your team can go through each document, and as the articles are reviewed and updated, the KB manager can immediately update the "Last Reviewed" date. The benefits are that there is no need for the team to manage a list of documents in a separate tracking document or ticketing system.
Identifying the Most Active Articles
An abbreviated version of this review cycle process may also be deployed for a subsection of the most popular documents in order to ensure that the documents that are providing the most value are as relevant as possible. To determine the selection of most popular content it is advised to use Jive's Community Manager Reports tool. You can use the reporting tools to find content based on the following attributes:
- Most commented
- Most viewed
- Most liked
During this type of review, it is also recommended that the knowledge base manager assess whether or not there is value in taking a single document and breaking it a part into a set of smaller materials. If you are finding that you have a single document that touches on a variety of topics, and the you're seeing that the comments on the document are often unrelated from one another, then that may be a signal that it is appropriate to separate out the content into different documents.
Identifying the Least Helpful Articles
There are several ways to determine what documents are considered the least helpful:
- Least viewed content in Community Manager Reports (CMR)
- google analytics - low page view
- Resonata - negative text / comments
- Documents with low ratings
During the content review cycle the knowledge base manager can prioritize articles that the community is finding the least helpful. The knowledge base team can analyze the content to find out why it is not helpful. Reasons may include:
- Content is incorrect
- Content is out of date
- Content is no longer relevant to the provided product or services
- Content is confusing
- Content is difficult to find
- Content is not optimized for searching
Finding least viewed content using CMR
The knowledge base manager can use CMR to get a complete list of documents in the Knowledge Base place, which can provide insight into what articles are returning the least views, which can aid the KB manager in determining what articles to review.
To find this, go to Reports > Content in Jive, and in the Content Leaderboard report click "Download CSV". The report can also be configured to show only views and activity in a certain time period.This will generate a CSV spreadsheet file that can be opened in Excel, where the knowledge base manager can sort the list of knowledge base articles by a series of metrics. CMR metrics that may be helpful are:
- Number of Views
- Number of Responses
- Number of Rates and Votes
- Number of Likes
It should be noted by the knowledge base manager that there may be a correlation between how long a document has existed and an increase in the number of views, likes, responses, etc. This should be considered when determining how successful a document is. An additional metric that can be used to find ineffective KB articles is by measuring the time users spend reading the articles. This is information that you can gather from Google Analytics, if you've correctly configured your Jive community with Google Analytics, as outlined in Setting up Google Analytics.
Determining Whether an Article is Permanent or Temporary
Nearly all articles that are produced will fall in one of two categories:
- Permanent: The content is valuable over a long period of time and the relevancy does not change over time
- Temporary: The content in the article is most valuable upon being published, and it will fall over time due to the content not being relevant.
An example of an Permanent article is a high level troubleshooting document or an article that defines a set of best practices. These articles can often be applied to a variety of topics and there will be little to update over time.
A Temporary article is often published to address a known issue, bug, or workaround, which has been addressed in later versions. This means that these articles are going to be most helpful when the issue is still unresolved or open, and as the issue is fixed over time, fewer people will need to reference the KB materials.
It is important that you are able to identify which of these two categories your various articles fall into as you perform your regular KB health check. It is not unusual to see temporary articles taking up most of the review effort, as these articles are the ones that are heavily dependent on specific versions and may be ones that are no longer relevant and will need to be retired.
Regarding new article production, it is also good to consider that out of a list of potential articles your team is going to write and publish, it may be worth prioritizing new temporary articles over new permanent articles. The reason being that your temporary articles are the most time sensitive materials, and the earlier you're able to identify and publish them, the more value you're going to gain.
Flagging items for review
In addition to relying on reports and having a regular review cycle where you cover 100% of your content, a great resource for identifying content that may be out of date or incorrect is by having the community flag articles that need to be reviewed.
There should be a link within each KB article that will alert the KB team whenever it is clicked by a community member. Similar to the KB Nomination customization, this custom feature can be added to your platform through the use of a custom Add-On.
In addition to this being a great method for the KB team to be aware of content that needs to be reviewed, this also provides a way for customers to become more involved in the support community.
Knowledge Base Engagement
The purpose of this phase is to increase adoption and visibility of your Knowledge Base place to ensure that your audience is effectively using the KB to find answers to their questions. All of the phases at this point lead up to this section, as this is the execution of gaining readership and reaching out to your audience. These methods include:
- Integration with your Case Creation process
- Engaging your Customers
- Engaging your Support Team
- Engaging your Organization
Integration with the Case Creation process
A primary goal of creating knowledge base articles is to reduce the number of new support cases created by customers and provide a way for customers to be self sufficient when solving technical issues.
One way to work towards this goal is to change the Case Creation Process to intercept customers from creating a new case where an existing KB document may instead solve their problem. There are multiple benefits to this:
- Speed to answer: Customers will find answers to their questions faster through a KB document than having to wait for a support rep to begin working the case
- KB Promotion and awareness: Customers will become more aware of the knowledge base over time and will begin to go to the knowledge base before creating a new case
- KB Improvement feedback loop: If the KB document does not answer the customer's question, then the newly created case will more than likely expose a flaw with the documentation that can be improved. This feeds into the efforts outlined in Maintaining the Knowledge Base.
In the screenshot example below, the first step in creating a new case is one where the customer will have to type in a case title. Based off of the text that the customer enters, the system will run a search for these terms against the knowledge base, as well as other information sources, such as official product documentation and peer to peer discussion threads.
If the customer is able to find an answer to their question at this point then it is expected that they will either abandon the case creation process, or they will click the "This answered my question" button. If the customer has not been able to find an answer, then they will click the "Create a new case" and proceed with completing the rest of the case creation form.
Here we see an example of a user creating a case with the title of "LDAP Sync Help" and then being presented a series of product documentation pages and knowledge base articles that match these search terms.
Engaging your Customers
Support representatives are encouraged to make use of the knowledge base content within their support cases. There are several reasons that a KB article may be referenced in a support case:
Why a KB article may be linked in a support case
- KB article has information necessary to resolve the customer case
- KB article has information can assist a case by lowering case resolution time by speeding up the case troubleshooting and investigation progress
Benefits to referencing a KB article within a support case
- Faster case communication and replies: KB articles are a great resource for including repeat content that may be referenced across multiple cases for any customer. These are documents that most often include steps necessary to provide support more information to troubleshoot a problem. These reduce the amount of time it takes a support rep from writing out instructions that apply to multiple customers. Example: How to gather Fiddler trace logs & How to gather Jive for Office / Outlook logs.
- Faster issue resolution: A customer may open a case that can be quickly answered by content that is in a knowledge base article. If this is the case, it is recommended that the support rep links to the document and can optional copy/paste specific content from the article into the case reply.
- Please note, it is not advised that support reps create a new copy or version of an existing KB document that is shared only with the customer. This opens the door to having multiple versions of the same document and can result in outdated materials that are not regularly maintained as a part of the KB process. When possible always rely on having a single source of truth for your knowledge base materials in order to avoid content fragmentation.
- KB Promotion and awareness: Customers will become more aware of the knowledge base over time and will begin to go to the knowledge base before creating a new case
Engaging your Support Team
Broadcasting out new KB materials to the support team
A problem you may find as you add content to your knowledge base space is that your support reps may work cases to conclusion without knowing that a relevant KB article exists - An article which could have resulted in a case being resolved sooner.
Although a great effort must be made in changing the troubleshooting and issue management behavior of your customers in a way that utilizes the benefits of the knowledge base, a similar effort should be made with your internal support team to ensure that they are aware of the content that resides in the knowledge base so that they can quickly utilize it in their case management process.
One way to address this issue is through doing regular blog posts or announcements that are broadcasted to your support team. The broadcast should highlight the following subjects:
- Newly articles published since last broadcast
- Recently updated articles
- Most popular articles
The broadcast is also a great opportunity to remind the support team to proactively request new KB articles for subjects or topics that are seeing a recent increase in activity. This solicitation is a key way for the KB manager to be aware of what topics to produce.
Utilizing Internal Knowledge Base Content
One source for new knowledge materials is by utilizing previously created content that resides in your internal content system. If you are using this as a possible source of content, it is recommended that after you publish a new KB article that utilizes this information, that you update the internal version to clearly outline that the internal content is also published in your external knowledge base.
The reason you want to post this notification on your internal content is to cover the scenario where your team is looking to resolve a customer issue and throughout their investigation they may find the internal material as a potential solution. Normally a support rep may simply copy and paste the content into the support case, but instead if we clearly outline that this content also lives in the external knowledge base, then the support rep can simply link to the KB article from within the case. This process will save the support rep time, where they no longer need to copy and paste content, and it also illustrate to the customer that there is valuable materials in the knowledge base that is directly related to their issues.
Engaging your Organization
Sharing news about the KB to your company
Despite the knowledge base being a tool primary managed and used by your technical support team, it is important that the entire organization is aware of the knowledge base and how it works.
If you have a team who handles new customer onboarding and training, it is recommended that this team includes the knowledge base as a part of their support training so that customers are aware of it as a possible resource for troubleshooting.
Having people within your organization voluntarily offer up new ideas for KB articles is a great resource for identifying new materials to produce - The best way to make this happen is to promote the KB and its success to the organization so that as people discuss customer related issues within your organization, they will be actively thinking about how the knowledge base can better address the issues in the future.
A secondary goal of promoting the KB internally is to raise awareness with project stakeholders and to ensure that the organization as a whole is aware of its positive impact. This may be important if your KB deployment is a new project that does not have complete buy in from leadership. Broadcasting out the KB reporting metrics and the KB ROI is a great way to illustrate the positive impact of the KB on your organization.
Measuring Success of your Knowledge Base
The primary goal of this phase is to establish and implement a series of metrics that can be gathered to objectively determine the success rate and effectiveness of the knowledge base program. Secondary goals include the ability to recognize trends and changes in the knowledge base effectiveness over time, and using this information to feed back into the production and maintenance of the content that lives in the KB.
Define Your Success Metrics
One the initial steps in establishing a successful KB reporting process is defining the key metrics you wish to measure in order to judge the success of the KB. See the sample list of metrics below for a recommended list of metrics, which can be gathered through the use of both Jive's Community Manager Report tools and Jive's integration with Google Analytics:
- Knowledge Base Articles found via Case Creation Wizard
- Knowledge Base Articles found outside of a Support Case
- Knowledge Base Articles found via a Support Case reference
- Number of KB Articles published
- KB Article Views
- Average time spent reading a KB article
- KB Article bounce rate
You will want collect measurements for each of these metrics on regular basis (weekly and/or monthly) so you can easily graph changes you see over time and project the health of the KB over time.
Measurement Weighting and Effectiveness
During the analysis of your measurements and the numbers you're able to retrieve from your reporting systems, you may find that some metrics are more valuable than others when compared directly with one another. For example, a user finding a document from your case creation wizard is more likely to result in a self-service experience where a new case was not created, as opposed to a user finding a KB article from a site wide search. Although both can result in positive self-service experiences, the chances of this being a successful case deflection is likely higher in the scenario where a user is recommended to an article during the case creation process.
Guest access to the Knowledge Base
As mentioned earlier in this guide, if your community allows Guest access then you will have to take this into consideration when analyzing your KB traffic metrics. Jive's Community Manager Reports (CMR) does not have a built in way to filter out activity from guests users - This can mean that if your audience is comprised of registered Jive users, then a percentage of your KB traffic will not be generated by your user base, but instead by guests who may or may not be your customers.
Integration with the Case Creation Process
If your support team is currently handling customer support through a case or ticket management system, then it is recommended that you integrate the case creation process that customers go through with your knowledge base, by adding the ability for customers to search through content that lives in the knowledge base based off of their issue. There are several reasons for this recommendation:
- Increase the opportunity for customers to find answers to their questions before opening a new case
- Trains and encourages customers indirectly to utilize the knowledge base prior to opening a new case
- Provides a way for customers to become familiar with the knowledge base and the type of content that resides within it
- Allows for the knowledge base manager to directly track case deflection rates when a customer starts the case creation process and abandons it due to finding a KB article
An ideal case creation process may look like the following:
- Customer wishes to create a new support case
- Customer initiates the Case Creation process
- Customer provides case details (Title, Description, Issue Type, etc)
- Case Creation process provides a list of recommended Knowledge Base articles
- Outcome A: Customer finds the answer to their question in a KB article
- Outcome B: Customer does not find the answer to their question and proceeds with creating a new customer case
The case creation process may also be integrated with other sources that may help resolve customer issues that are not the knowledge base, such as product documentation or peer to peer discussion forums where community members help each other resolve issues.
The case creation integration between the Jive systems and the ticketing system is most likely going to be done via use of Jive's v3 API system. Specifically the Search Service. Documentation around how to use the v3 API system can be found here: Jive REST Rest API v3
Setting up Google Analytics
Enabling Google Analytics on your site allows you to gather and analyze data around the path that users take as they navigate from page to page within your site. This tells you not only the number of people who are finding your content, but more importantly how and where they are finding the content. This context can inform you on the success of your knowledge base and can assist you in building metrics that directly relate to the ROI of your knowledge base.
If you do not have a Google Analytics account, or a tracking code, you will need to first set this up at http://www.google.com/analytics/
Please note, this Third-Party Analytics field is hidden for Jive Cloud customers. If you want to use this functionality to track custom Google Analytics data points then you will need to open a new support ticket with Jive.
Google Analytics Configuration
You will need to configure your Google Analytics in such a way that you're able to track the Jive Place (Container) that the page view was on. Without doing this, by default Google Analytics is not able to report back on what traffic is related to what spaces or social groups. You will define a Custom Dimension that allows you to tell Google Analytics what space or social group a piece of content belongs to. This enables you to build custom reports where you can report on traffic in only specific places, such as the knowledge base.
To configure this, you will need to go to Google Analytics, open your analytics profile, and then go to Admin > Custom Definitions. Create a new definition with the following properties:
- Name: Jive Container
- Scope: Hit
- Active: checked
You will also need to note the dimension index for the newly created custom dimension. This can be found by going to your list of custom dimensions and referencing the "Index" column. You will need this number below.
You will need to go to Admin Console: System > Settings > Third-Party Analytics and edit the analytics tracking embed code to allow you to start tracking pages using this custom dimension. Find the line in your embed code that says either ga('send', 'pageview'); or _gaq.push(['_trackPageview']); and add the following code before the pageview line:
var containerString = jive.global.containerType.toString() + ':' + jive.global.containerID.toString();
_gaq.push(['_setCustomVar', [CustomDimensionIndex], 'JiveContainer', containerString, 3]);
Important note: Be sure to replace [CustomDimensionIndex] with the correct index number of your newly created Custom Dimension. This is likely a number between 1 and 10, depending on how many custom dimensions you have previously set up.
Building Google Analytics User Path Flow Sequences to Track KB Success
The primary feature of Google Analytics that you can use to measure KB success is the "User Flow" report. This allows you to build custom rules to see how users may navigate from page to page within your support community, and you can report on the number of sessions that match these page path rules.
For example, you may build a Sequence rule that would match the following user path:
- Step 1: Page loaded with title of "Start new case"
- Is immediately followed by...
- Step 2: Page loaded that is in the Knowledge Base Space and is a document
- Is followed by...
- Step 3: Page Title does not match "Start new case"
- Is followed by...
- Step 4: Page is not a Support Case
This would be an example of a user path for a user who begins the process of creating a new case, but before they create one, they instead immediately navigate to a knowledge base article (Likely because of a recommendation from the Case Creation Process integration with the KB).
The Google Analytics report will be able to tell you how many unique sessions completed this path across a timeframe of your choosing.
Here is an example output of a custom User Flow - This includes all user sessions who meet your specified sequence rules. The number highlighted in red is the total number of sessions that fit your sequence.
You can review Google's documentation on this functionality here:
Build a Custom Sequence
To build a Sequence like the provided example above, you will need to go into Google Analytics > Audience > User Flow reports
From here you will see a graph of all user flow paths for your entire site. The goal here is to build a custom sequence that matches an expected user flow that would result in a successful self-service experience or deflected case that is tied to your knowledge base.
Click "Add Segment" at the top of the page to start creating a new sequence.
Next you will need to select the type of Segment. Select "Sequences" under Advanced
Here you will be able configure various steps and rules to construct a sequence of pages that you expect users to flow through in a single session.
If you wish to include a step that requires that someone views a document in your knowledge base space you will need to utilize the recently setup Custom Dimension called "Jive Container". Here is an example of a page view that is a document in the knowledge base space.
Please note, you will need to update the value for the Jive Container dimension so that instead of it being ##:#### it matches the correct ID for the knowledge base space in your community. For example, it may look like 14:1234 or 700:34344. See the section below for how to identify the correct Jive Container ID for your community.
How to get your Jive Container Dimension Value for the Knowledge Base
The format for the Jive Container dimension value is the following format: [ContainerType]:[ContainerID]. The ContainerType and ContainerID will both be numbers specific to your Jive community.
The ContainerType for spaces is 14. ContainerType for Social Groups is 700.
You can retrieve the ContainerID for your knowledge base place by starting to create a new document in your place, and inspecting the "ContainerID" value in the URL of the page when you're crafting a new document. For example, the Jive Container value for the following example would be 14:2023
You would then configure the step in your Google Analytics Sequence to look like the following:
Sample Sequences to measure KB Success
There are three Knowledge Base success metrics we can gather by using Google Analytics User Flow Reports. You can use these as a basis for your own success metrics. These samples assume that you are integrating your knowledge base with your case / ticketing system, and that both are integrated into your Jive community.
User Flow Sample 1: Knowledge Base Articles found via Case Creation Wizard
Summary: How many sessions exist where a user started the Case Creation Wizard, immediately goes to a Document in the KB space, and then never goes back to either starting a new case or completing a new case
User Flow Sample 2: Knowledge Base Articles found outside of a Support Case
Summary: How many sessions exist where a user views a Discussion in the KB space, and never starts the Case Creation Wizard or views a Case
User Flow Sample 3: Knowledge Base Articles found via a Support Case reference
Summary: How many sessions exist where a user views a Case, and then immediately goes to a Document in the KB space (This is considered a KB article Assisting a Case)
Gathering metrics from your User Flow sequences
Once you have built your various User Flow Sequences, you can use the top bar in the Users Flow page to select each of your segments / sequences (1), then you can select the time frame for your data (2), and then you will be able to see the number of users who are in the segment for that given time period (3).
This number, outlined in red, is the number you will need to record in your KB success metric spreadsheet.
Gathering Metrics from Community Manager Reports (CMR)
There are several key metrics you can capture through Jive's Community Manager Reports (CMR) tool that will help you track the success and health of the knowledge base:
- Total number of Documents
- Active users
- Participating users
As with the Google Analytics reports, you will need to capture these metrics on a regular basis so you can report on any upward or downward trends over time. This will also allow you to directly compare the case deflection and self-service metrics to the rate of new content being created and user engagement. It is expected that both of these metrics will be directly related to one another.
Formatting and presenting your KB Metrics
As you gather your various metrics from your reporting systems, like Google Analytics and CMR, it is recommended that you collect them in a spreadsheet that you update weekly. See the following table for an example of how to format and present your data.
An additional data point you can calculate based on your existing captured metrics is the Ratio of KB Article Finds vs. New Cases Created. Typically you will be using tools like Google Analytics and CMR to measure activity of your KB content, but this type of 'ratio' metric will give you additional context around how effective the KB is compared to the activity of new incoming support issues. For example, you may see trends where as the number of new incoming support cases decreases, the amount of activity in the knowledge base may stay the same or even rise.
|Metric Source||Week 1||Week 2||Week 3||Week 4|
|Metric 1: Knowledge Base Articles found via Case Creation Wizard||Google Analytics||81||86||113||90|
|Metric 2: Knowledge Base Articles found outside of the Case Creation Wizard or a Case||Google Analytics||216||233||260||224|
|Metric 3: Knowledge Base Articles found via a Support Case reference||Google Analytics||112||130||142||132|
|Metric 4: Total New Cases Created||3rd Party Ticket System||500||505||508||504|
|Metric 5: Total New KB Articles Published||CMR||4||6||3||1|
|Metric 6: Active Users in KB Space||CMR||65||67||69||58|
|Metric 7: Participating Users in KB Space||CMR||30||27||29||30|
|Ratio of KB Articles found via Case Creation vs New Cases Created||Hybrid||16.2%||17.0%||22.2%||17.9%|