Difference between revisions of "Best Practices for Building a Taxonomy for Pega Knowledge"

From PegaWiki
Best Practices for Building a Taxonomy for Pega Knowledge
Jump to navigation Jump to search
(Removed unnecessary TOC)
Tag: Visual edit
m (Updated Capability area from Knowledge Mangement Application to Knowledge management to test a bug fix)
Tag: Visual edit: Switched
 
(21 intermediate revisions by 7 users not shown)
Line 1: Line 1:
{{New request
+
{{Design pattern
 
+
|Title= Best practices for building a taxonomy for Pega Knowledge
|Request to Publish=
+
|Description= Learn best practices for building taxonomies for Pega Knowledge
 
+
|Version= 8.4
|Curator Assigned=
+
|Applications= Pega Customer Service
 
+
|Capability Area= Knowledge Management
 +
|Owner= Scott Kennedy
 
}}
 
}}
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓  '''<big>Please Read Below</big>'''  ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
 
 
Enter your content below. Use the basic wiki template that is provided to organize your content.  After making your edits, add a summary comment that briefly describes your work, and then click "SAVE".  To edit your content later, select the page from your "Watchlist" summary.  If you can not find your article, search the design pattern title.
 
 
When your content is ready for publishing, next to the '''"Request to Publish"''' field above, type '''"Yes"'''. A Curator then reviews and publishes the content, which might take up to 48 hours.
 
 
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ '''<big>The above text will be removed prior to being published</big>''' ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
 
 
'''Best Practices - Building a Taxonomy for Pega Knowledge'''
 
  
 
= Summary =
 
= Summary =
Building out a taxonomy for Pega Knowledge is best done collaboratively, leveraging the expertise of the business/contact center and your knowledge team members. The Pega Knowledge taxonomy provides flexibility in how it is created and maintained, supporting a hierarchical structure with top level and child/sub-level categories. To define a taxonomy that best aligns with your business needs, we recommend the following:
+
Building out a taxonomy for Pega Knowledge is best done collaboratively, leveraging the expertise of the business or contact center, and your Knowledge team members. The Pega Knowledge taxonomy provides flexibility in how it is created and maintained, supporting a hierarchical structure with top level and child or sub-level categories. This article describes best practices for defining a taxonomy that best aligns with your business needs
  
== Get familiar with out-of-the-box taxonomy and capabilities for Pega Knowledge ==
+
== Becoming familiar with out-of-the-box taxonomy and capabilities for Pega Knowledge ==
* Install a Dev or sandbox instance of Pega Knowledge
+
* Install a Development or sandbox instance of Pega Knowledge
* Read the Pega Knowledge User Guide (<nowiki>https://community.pega.com/knowledgebase/products/knowledge</nowiki>)
+
* Read the [https://community.pega.com/knowledgebase/products/knowledge Pega Knowledge User Guide]
* Provide access to the business/knowledge team responsible for creating, maintaining, and publishing knowledge content, and the taxonomy categories
+
* Provide access to the business/knowledge team responsible for creating, maintaining and publishing knowledge content, and the taxonomy categories
* Create a draft taxonomy, experiment to identify the optimal category structure for your business needs now and as your business evolves
+
* Create a draft taxonomy and experiment to identify the optimal category structure for your business needs now, and as your business evolves
  
== Assess impacts of your legacy knowledge content to the taxonomy ==
+
== Assessing the impact of your legacy knowledge content on the taxonomy ==
 
* Identify legacy content that needs to be migrated to Pega Knowledge
 
* Identify legacy content that needs to be migrated to Pega Knowledge
* Ensure the taxonomy structure supports both legacy and new knowledge content – Don’t design yourselves into a corner, the taxonomy design should be flexible enough to grow with your knowledge base and business
+
* Ensure that the taxonomy structure supports both legacy and new knowledge content – Do not design yourself into a corner. The taxonomy design should be flexible enough to grow with your knowledge base and business
  
== Achieve business alignment on your taxonomy structure ==
+
== Achieving business alignment on your taxonomy structure ==
 
* If a current taxonomy structure exists and works well, then implement it  
 
* If a current taxonomy structure exists and works well, then implement it  
* If the current taxonomy is insufficient, or does not exist, engage the business team to determine: Basis of the taxonomy structure, which could be based on your:
+
* If the current taxonomy is insufficient or does not exist, engage the business team to determine the basis of the taxonomy structure, which could be based on your:
 
'''Product or service offerings'''
 
'''Product or service offerings'''
  
 
Top level category: Product line XYZ
 
Top level category: Product line XYZ
  
  Sub-category: Product A
+
  Sub-category: Product A
  
 
Sub-category: Product A Features
 
Sub-category: Product A Features
  
  Sub-category: Product B
+
  Sub-category: Product B
  
 
Sub-category: Product B Features
 
Sub-category: Product B Features
  
'''Organizational structure''' (e.g. for banking: Customer Service, Retail Banking, Commercial Banking, Credit/debit card, Loans – home, auto, etc.) – See '''Screenshot #1'''
+
'''Organizational structure''' (for example, banking: Customer Service, Retail Banking, Commercial Banking, Credit/debit card, Loans – home and auto) – See '''Taxonomy structure''' example.
  
 
Top level category: Customer Service
 
Top level category: Customer Service
  
  Sub-category: Commercial Banking  
+
  Sub-category: Commercial Banking  
  
 
Sub-category: Retail Banking
 
Sub-category: Retail Banking
Line 57: Line 49:
  
 
        Sub-category: Transactions         
 
        Sub-category: Transactions         
 +
 +
'''Example: Taxonomy structure'''
 +
 +
[[File:TaxonomyExample.jpg|border|807x807px]]
  
 
'''Regions/Languages'''
 
'''Regions/Languages'''
Line 62: Line 58:
 
Top level category: North America
 
Top level category: North America
  
  Sub-category: United States
+
  Sub-category: United States
  
  Sub-category: Canada
+
  Sub-category: Canada
  
 
Top level category: EMEA
 
Top level category: EMEA
  
  Sub-category: Germany
+
  Sub-category: Germany
  
  Sub-category: France
+
  Sub-category: France
  
  Sub-category: Italy
+
  Sub-category: Italy
  
'''Knowledge Content'''; such as “How-To’s”, Methods & Procedures, Regulatory, Customer/Member only, Internal/Proprietary only, etc.
+
'''Knowledge Content'''; such as How-To documents, Methods and Procedures, Regulatory documents, Customer/Member only documents and Internal/Proprietary only documents.
  
Top level category: Methods and Procedures
+
Top level category: Methods & Procedures
  
  Sub-Category: Handling Disputes
+
  Sub-Category: Handling Disputes
  
  Sub-category: Handling Wire Transfers
+
  Sub-category: Handling Wire Transfers
  
 
'''Combination of the above or another structure that provides a logical way to classify your articles'''
 
'''Combination of the above or another structure that provides a logical way to classify your articles'''
  
== Number of taxonomy category sub-levels ==
+
== Creating taxonomy category sub-levels ==
* Avoid an overly-complex taxonomy design, as it becomes counter-productive from an organization and maintenance perspective
+
* Avoid an overly-complex taxonomy design, as it becomes counter-productive from an organization and maintenance perspective.
* Start with two to three sub-category levels, gather feedback from business team, and use it to iterate the design
+
* Start with two to three sub-category levels, gather feedback from business team, and then use it to iterate the design.
  
 
== Naming categories ==
 
== Naming categories ==
* Use short, concise category descriptions: e.g. Methods & Procedures, Customer Service, Sales – Inbound, Sales – Outbound, Q & A, How-to’s, Training
+
* Use short, concise category descriptions: for example, Methods & Procedures, Customer Service, Sales – Inbound, Sales – Outbound, Q & A, How-To, and Training
 
* Do not use sentences
 
* Do not use sentences
* Be consistent with either “Title Case” or “Sentence case”, do not mix
+
* Be consistent with either “Title Case” or “Sentence case" - do not mix
  
 
== Using category images ==
 
== Using category images ==
* Category ‘icons’ (50x50 pixel images) can be set for each category and are used in the Tiles layout display in KM Help Sites as a visual indicator for the categories. Display of the icons are a configurable option in the Help Site editor
+
* Category ‘icons’ (50x50 pixel images) can be set for each category and are used in the Tiles layout display in KM Help Sites as a visual indicator for the categories. Display of the icons are a configurable option in the Help Site editor.
  
== Setting content visibility/security ==
+
== Setting content visibility and security ==
* When certain articles should only be available or visible to specific groups of end users, you can set content visibility restrictions at the taxonomy category level by specifying a related Access Role on the related category.  All articles linked to that category and any related sub-categories will require users to have that Access Role in order to view those articles
+
* When specific articles should be available or visible only to specific groups of end users, you can set content visibility restrictions at the taxonomy category level by specifying a related Access Role on the related category.  All articles linked to that category and any related sub-categories will require users to have that Access Role in order to view those articles.
  
* For example, a category may be created for manager-only articles, such as topics private topics around personnel reviews and procedures. - See '''Screenshot #2'''
+
* For example, you can create a category for manager-only articles that contain topics related to personnel reviews and procedures. - See '''Setting content visibility''' example'''.'''
'''Screenshot #1'''
 
  
[[File:TaxonomyExample.jpg|border|807x807px]]
 
  
'''Screenshot #2'''
+
'''Example: Setting content visibility'''
  
 
[[File:EditCategory.jpg|border|877x877px]]
 
[[File:EditCategory.jpg|border|877x877px]]

Latest revision as of 07:46, 7 March 2022

Best practices for building a taxonomy for Pega Knowledge

Description Learn best practices for building taxonomies for Pega Knowledge
Version as of 8.4
Application Pega Customer Service
Capability/Industry Area Knowledge Management



Summary[edit]

Building out a taxonomy for Pega Knowledge is best done collaboratively, leveraging the expertise of the business or contact center, and your Knowledge team members. The Pega Knowledge taxonomy provides flexibility in how it is created and maintained, supporting a hierarchical structure with top level and child or sub-level categories. This article describes best practices for defining a taxonomy that best aligns with your business needs.

Becoming familiar with out-of-the-box taxonomy and capabilities for Pega Knowledge[edit]

  • Install a Development or sandbox instance of Pega Knowledge
  • Read the Pega Knowledge User Guide
  • Provide access to the business/knowledge team responsible for creating, maintaining and publishing knowledge content, and the taxonomy categories
  • Create a draft taxonomy and experiment to identify the optimal category structure for your business needs now, and as your business evolves

Assessing the impact of your legacy knowledge content on the taxonomy[edit]

  • Identify legacy content that needs to be migrated to Pega Knowledge
  • Ensure that the taxonomy structure supports both legacy and new knowledge content – Do not design yourself into a corner. The taxonomy design should be flexible enough to grow with your knowledge base and business

Achieving business alignment on your taxonomy structure[edit]

  • If a current taxonomy structure exists and works well, then implement it
  • If the current taxonomy is insufficient or does not exist, engage the business team to determine the basis of the taxonomy structure, which could be based on your:

Product or service offerings

Top level category: Product line XYZ

  Sub-category: Product A

Sub-category: Product A Features

  Sub-category: Product B

Sub-category: Product B Features

Organizational structure (for example, banking: Customer Service, Retail Banking, Commercial Banking, Credit/debit card, Loans – home and auto) – See Taxonomy structure example.

Top level category: Customer Service

  Sub-category: Commercial Banking

Sub-category: Retail Banking

        Sub-category: ATM Locations

        Sub-category: Credit/Debit Cards

        Sub-category: Transactions       

Example: Taxonomy structure

TaxonomyExample.jpg

Regions/Languages

Top level category: North America

  Sub-category: United States

  Sub-category: Canada

Top level category: EMEA

  Sub-category: Germany

  Sub-category: France

  Sub-category: Italy

Knowledge Content; such as How-To documents, Methods and Procedures, Regulatory documents, Customer/Member only documents and Internal/Proprietary only documents.

Top level category: Methods & Procedures

  Sub-Category: Handling Disputes

  Sub-category: Handling Wire Transfers

Combination of the above or another structure that provides a logical way to classify your articles

Creating taxonomy category sub-levels[edit]

  • Avoid an overly-complex taxonomy design, as it becomes counter-productive from an organization and maintenance perspective.
  • Start with two to three sub-category levels, gather feedback from business team, and then use it to iterate the design.

Naming categories[edit]

  • Use short, concise category descriptions: for example, Methods & Procedures, Customer Service, Sales – Inbound, Sales – Outbound, Q & A, How-To, and Training
  • Do not use sentences
  • Be consistent with either “Title Case” or “Sentence case" - do not mix

Using category images[edit]

  • Category ‘icons’ (50x50 pixel images) can be set for each category and are used in the Tiles layout display in KM Help Sites as a visual indicator for the categories. Display of the icons are a configurable option in the Help Site editor.

Setting content visibility and security[edit]

  • When specific articles should be available or visible only to specific groups of end users, you can set content visibility restrictions at the taxonomy category level by specifying a related Access Role on the related category.  All articles linked to that category and any related sub-categories will require users to have that Access Role in order to view those articles.
  • For example, you can create a category for manager-only articles that contain topics related to personnel reviews and procedures. - See Setting content visibility example.


Example: Setting content visibility

EditCategory.jpg