Troubleshooter best practices

This video describes best practices to use when creating and testing a Pega Knowledge Troubleshooter.

Now, let’s look at the best practices to follow when you create, test, and preview a troubleshooter.

A troubleshooter includes a series of questions or steps. Make sure that questions and information/answers are clear and concise. 
As you add decisions and branching to your troubleshooter, you want to focus on each guided step and keep each step as straightforward and simple as possible. Doing so helps both external customers and CSRs and prevents the troubleshooter from becoming too complicated.
The first example shows a poorly-designed question and answer. There are multiple questions; the meaning of the questions is not clear — how could a customer know whether they have the “right” cable? How could they know if the cable is approved? Also, the answer includes information about restarting the cable service, which is not associated with checking that the cables are connected. 

The second example shows a well-designed question and answer. There is one question associated with the step, and the information provided applies only to that question.

Another best practice is to use high-quality images and videos to assist users with steps that require more detail or clarification. 
High quality does not mean the highest resolution and 10-megabyte file sizes. Images should be less than 3 megabytes to avoid performance issues when running the troubleshooter.
In the example, the image helps the customer locate the power light and shows that when the light is green, the power is on.

Guided troubleshooting allows visually-engaging content, but you do not need an image with every single step. For example, the following question does not need an image.

As a best practice, you  should add related  knowledge articles to the associated step. Related articles can help both the customer service representative (CSR) and customer learn about similar issues and have a resolution path if their initial problem is not resolved. Consider using a suggested action to provide a path for the customer to open a service case.
Avoid confusing users with too many related articles or attachments.
In the first example, the customer has too many unrelated paths that they could pursue in the related articles section. Some of the related articles are not about connecting the set-top box.

In the second example, if the question is not fully understood; the customer can take the suggested action and follow-up with a  CSR. The customer or CSR could also investigate one of the issues discussed in the related articles.

There are several best practices you can use to improve the customer’s ability to navigate.
When  a troubleshooter reaches the last step, and the issue is still unresolved, you might want to launch another troubleshooter  to get to a resolution.
If there are several potential diagnosis paths, create separate troubleshooters that the customer or CSR can launch from within a troubleshooter.
When appropriate, leverage your service cases as a suggested action. A customer who has not been able to resolve the issue by using the troubleshooter can use a suggested service case to move from an unassisted channel to an assisted channel and get help from a CSR.
When configuring the troubleshooter categories in the Pega Knowledge authoring portal, make sure the categories are clear and that the options are relevant to your customers.

In the Interaction Portal or self-service web site, selecting the product/service, problem type, then sub-problem type to launch the corresponding troubleshooter should be easy to understand and relevant.
Finally, it is a best practice to review and test your troubleshooter before making it available to users. 
In the Pega Knowledge Troubleshooters tabs, use the grid view and graphical view to review the question order for your troubleshooter.
The grid view shows a list of the questions/steps and the question type.

The graphical view shows a tree view, which lets you more easily see the order and the area to which the steps branch.

Test your troubleshooter by using the Preview capability. Preview shows the troubleshooter as it appears to the user and lets you review each step before publishing the troubleshooter.

Test, test, test! Run through your troubleshooter over and over to ensure the steps are in a logical order.