Difference between revisions of "Best Practices for Building a Taxonomy for Pega Knowledge"
ScottKennedy (talk | contribs) (Initial edits) Tag: Visual edit |
ScottKennedy (talk | contribs) (Removed unnecessary TOC) Tag: Visual edit |
||
Line 14: | Line 14: | ||
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ '''<big>The above text will be removed prior to being published</big>''' ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ | ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ '''<big>The above text will be removed prior to being published</big>''' ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ | ||
− | '''Best | + | '''Best Practices - Building a Taxonomy for Pega Knowledge''' |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
= Summary = | = Summary = |
Revision as of 13:25, 2 September 2020
Curator Assigned | |
---|---|
Request to Publish | |
Description | |
Version as of | |
Application | |
Capability/Industry Area |
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ Please Read Below ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
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.
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ The above text will be removed prior to being published ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
Best Practices - Building a Taxonomy for Pega Knowledge
Summary[edit]
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
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’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 #1
Screenshot #2