View source for Best Practices for Building a Taxonomy for Pega Knowledge

Best Practices for Building a Taxonomy for Pega Knowledge / ← Best practices for building a taxonomy for Pega Knowledge

You do not have permission to edit this page, for the following reasons:

• The action you have requested is limited to users in the group: editor.
• The action you have requested is limited to users in one of the groups: editor, Administrators.

---

You can view and copy the source of this page.

{{Design pattern |Title= Best practices for building a taxonomy for Pega Knowledge |Description= Learn best practices for building taxonomies for Pega Knowledge |Version= 8.4 |Applications= Pega Customer Service |Capability Area= Knowledge Management |Owner= Scott Kennedy }} = Summary = 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 == * Install a Development or sandbox instance of Pega Knowledge * 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 * 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 == * 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 == * 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''' [[File:TaxonomyExample.jpg|border|807x807px]] '''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 == * 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 == * 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 == * 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 == * 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''' [[File:EditCategory.jpg|border|877x877px]]

Return to Best practices for building a taxonomy for Pega Knowledge.