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
(adjusted the as of version)
Tag: Visual edit
m (Heeger, walter moved page Best Practices - Building a Taxonomy for Pega Knowledge to Best practices for building a taxonomy for Pega Knowledge without leaving a redirect: removing Best practices from Title)
Line 2: Line 2:
|Title= Editing Best Practices - Building a Taxonomy for Pega Knowledge
|Title= Editing Best Practices - Building a Taxonomy for Pega Knowledge
|Description= Building Taxonomies for Pega Knowledge Editorial Best Practices  
|Description= Building Taxonomies for Pega Knowledge Editorial Best Practices  
|Version= 8.5
|Version= 8.4
|Applications= Customer Service
|Applications= Customer Service
|Capability Area= Knowledge Management
|Capability Area= Knowledge Management
|Owner= Scott Kennedy
|Owner= Scott Kennedy
'''Best Practices - Building a Taxonomy for Pega Knowledge'''
= Summary =
= Summary =

Revision as of 20:28, 17 September 2020

Editing Best Practices - Building a Taxonomy for Pega Knowledge

Description Building Taxonomies for Pega Knowledge Editorial Best Practices
Version as of 8.4
Application Customer Service
Capability/Industry Area Knowledge Management

Best Practices - Building a Taxonomy for Pega Knowledge


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:

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

  • Install a Dev or sandbox instance of Pega Knowledge
  • Read the Pega Knowledge User Guide (https://community.pega.com/knowledgebase/products/knowledge)
  • 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

Assess impacts of your legacy knowledge content to the taxonomy[edit]

  • 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

Achieve 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: 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 (e.g. for banking: Customer Service, Retail Banking, Commercial Banking, Credit/debit card, Loans – home, auto, etc.) – See Screenshot #1

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       

Screenshot #1



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’s”, Methods & Procedures, Regulatory, Customer/Member only, Internal/Proprietary only, etc.

Top level category: Methods and 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

Number of 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 use it to iterate the design

Naming categories[edit]

  • Use short, concise category descriptions: e.g. Methods & Procedures, Customer Service, Sales – Inbound, Sales – Outbound, Q & A, How-to’s, 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/security[edit]

  • 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
  • For example, a category may be created for manager-only articles, such as topics private topics around personnel reviews and procedures. - See Screenshot #2

Screenshot #2