Gainsight's Risk Management framework provides a comprehensive view of our customer relationships. This empowers CSMs to deliver A+ service while maintaining visibility across the organization. We had four objectives in mind when designing our Risk Management framework:

  1. Address early warning signs
  2. Incorporate the CSM’s judgment into the assessment of the risk level
  3. Establish a common view of risks across levels of the organization
  4. Hold other departments accountable for addressing risks

For more information on Gainsight's risk management framework, refer to the How Gainsight uses Scorecards and Calls to Action blog post. This article focuses on setting up CTA reasons and rules to support the Product Risk.

Creating CTAs for Product Risk

Having trouble understanding the difference between Support, Quality and Product Risks?

  • Support: risks based on volume, duration or priority of support cases. They can be any type of support cases.
  • Quality: risks based on volume or priority of support cases that are specifically designated as bugs. This is a valuable subset of support cases that we believe is worth tracking individually.
  • Product: support cases based on product limitations or functionality misunderstandings. The product is working as designed. However, the user is unsatisfied with the functionality or does not find the functionality to be intuitive.

We recommend two types of Product Risk CTAs:

  1. Support Ticket identified as Product Risk (automatic----generated by Rule)
  2. Manually opened Product Risk CTA. This can be created by a CSM for any problem they deem as a Product Risk.

Please note this guide is optimized for a Zendesk integration. However, the concepts are very similar for different support integration.

Create CTA Reason & Custom Fields for Tracking Product Risk

First, add a new CTA Reason called Product Risk. Learn how to add a new CTA Reason here. We also recommend you create a CTA Reason called Product Risk Manual, for the Product Risk CTAs that will be opened manually by CSMs.

To track tickets that are identified by Support as Product Risks, we recommend you create a Product Risk Custom Field checkbox on the SFDC Zendesk Ticket object. (pictured above)

It will be necessary to advise your Support team on how to use this checkbox. Proper use of this checkbox will be crucial for your rule to identify Product Risk tickets.

Building Rule for “Product Risk: Support Ticket Identified as Product Risk” CTA

1. Navigate to Administration > Rules Engine. Click +RULE.

  • Select the Custom Rule Type
  • Enter the Rule Name: Product risk: ticket marked as Product Risk
  • (Optional) Enter Description: Looks for support tickets that are tagged/checked as Product Risk and triggers a CTA

2. Click NEXT to save, and move to the Setup Rule screen.

Rule Show Fields

Select the Zendesk Ticket object to build the rule on, since we want to trigger CTAs based on Zendesk Tickets. We have included a lot of fields in the Show section, since we like to use them as tokens in our CTA comments. A token is a specific piece of information that can be brought from the record (in this case, a Zendesk ticket) into the CTA.

Rule Filters

In the Filter section, note that we are looking for tickets where the new ZendeskTicket::Product Risk checkbox has been checked. We’re also filtering by ZendeskTicket::Status includes New, Open, Pending or Hold.

You could consider removing the ZendeskTicket::Status filter, since sometimes Product Risks persist after the Support Ticket is closed. This is because a Product Risk often cannot be addressed by a Support team, so they will close the ticket. Coordinate with your Support team on how to handle tickets where they’ve checked the Product Risk checkbox.

Rule Action Setup

Set Action Type to Call to Action. We’ve applied a custom “Product risk” playbook, and we also included a lot of tokens in the CTA Comments section. There are no Criteria for this action.

Test & Schedule Rule

Be sure to test your rule thoroughly. Testing is a really critical stage to make sure the rule is working as planned. Otherwise, you could overflow your CSMs with CTAs, issue no CTAs at all, or the rule could fail. Make sure you leave the Test Run box checked while you’re running your tests.

Once your rule is working as planned, schedule it! To schedule a rule, navigate to the Rules Engine and toggle the On/Off switch to On. Once a rule is On, the Schedule tab will appear next to Setup Action.

We recommend scheduling a Product Risk: Ticket Marked as Product Risk rule to run daily, usually in the early morning hours. There’s no need to run this rule historically, so leave the Run for historical periods unchecked. Click the green Schedule button.

Be sure to monitor your rule, especially in the first few weeks that it is running. Sometimes logical flaws with unusual cases will emerge that did not show up in testing.