Editing Best Practices - Building a Taxonomy for Pega Knowledge

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

edit liked pages

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:

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

• 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

• 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

• 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

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

• 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

• 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

• 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

• 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

A business solution that automates workflows in your organization. Multiple, unrelated applications can be hosted in the same system. You create an application by running the New Application wizard.

A program component that defines and implements an interface between an external application acting as a client, and a Pega Platform system acting as a server. An external system can send a request to a Pega Platform application and receive a response.

For example, the Pega Cloud Services SFTP service provides Pega Cloud clients with simple, secure file transfers to and from their Pega Cloud applications.

1) In user portals, a "team" is equivalent to a "work group". 2) One or more associates who work semi-autonomously on recurring tasks or towards a common goal. In a Pega Workforce Intelligence hierarchy, departments are comprised of teams. (Defined by the WFI team)

A durable, potentially permanent, saved representation of a concrete class that is stored in the database. An instance corresponds to a row in the relational database, or to a record. An instance consists of properties and values, and some of these property values form a unique key to the instance.

A work party that typically initiates a case. In many applications, only one customer can be associated with a case.

Actual work that is performed by application users and automations that consists of a sequence of tasks and leads to an intended business goal. An example of a case is a process of hiring a particular job candidate, where an HR worker collects necessary documents, a hiring manager conducts a job interview, and an application sends an automated email with onboarding information after the candidate is approved. To create a case, you first build a template of your business process that is a case type, and then apply the template in multiple cases, for example, to review applications from many candidates.

Actual work that is performed by application users and automations that consists of a sequence of tasks and leads to an intended business goal. An example of a case is a process of hiring a particular job candidate, where an HR worker collects necessary documents, a hiring manager conducts a job interview, and an application sends an automated email with onboarding information after the candidate is approved. To create a case, you first build a template of your business process that is a case type, and then apply the template in multiple cases, for example, to review applications from many candidates.

(Deprecated) A configuration of panels (areas) in a harness that support a composite portal. Existing panel sets continue to function. As a best practice, upgrade panel sets to screen layouts.

A role that defines the classes that a user can view, update, and delete through the Access of Role to Object and Access Deny rule types.