Solved

Type/Reason best practices

  • 15 May 2019
  • 4 replies
  • 175 views

We're very new to Gainsight (launched less than 2 weeks ago) and are struggling with the best way to set up CTA types and reasons, hoping people have some advice.



Is it better to limit CTA reasons to specific CTA types, or leave them as global? I'm having a hard time divining what our reporting needs will be 6, 8, 12 months from now, and it seems that it's extraordinarily difficult to change your CTA type/structure later, as you can't delete or deactivate any types or reasons that are in use by a CTA. We're fresh enough in to this that we could go either way, but I can imagine how hard it would be to try and move all your global reasons under specific CTAs 6 months later when there are hundreds or thousands of CTAs using those reasons.



Part of what's tripping us up is that CTAs made off time-line entries all default to type "activity" and don't have a reason unless you go back and add one later. There's a fear that if, for example, we move all the 'risk' reasons under the 'risk' CTA types, we would never be able retroactively categorize Timeline To-do's as risks. Is that a valid fear? Is there ever a use-case where people have tried to go back and add reasons to their timeline to-do's? Is it better to keep your risk reasons contained under the risk CTA type, or is it not really a problem if someone makes a lifecycle CTA and gives it a reason 'Bugs risk'?



Not really sure the best path forward here, or what we'll be kicking ourselves for later. I'm trying to avoid a herculean data cleanup in 6 months where we blow away hundreds of CTAs and recreate them under a new data structure.


icon

Best answer by john_apple 15 May 2019, 20:26

View original

4 replies

Userlevel 7
Badge +3
We started out with all of our reason codes global, and we found it was very confusing for our end users and caused reporting challenges, therefore we had to go through the hefty effort of going back to change them so that reasons were tied to CTA Types. I would recommend starting out with limiting your Reason codes to specific CTA types.



For manual risk identification, we advise our CSMs to create the appropriate CTA using the RISK type, and then capture any Timeline entries through the CTA. We advise them to use the general timeline and tasks created via Timeline for more routine items. This way we can ensure a single process for Risk tracking.



Others may have other ideas, but this is how we have done it.


Thanks Jeff, I'll share that feedback with the team


Userlevel 6
Badge +5
I would also recommend creating Reasons under specific Types rather than Global. We currently have a disorganized setup where Reasons can be associated to any Type. Additionally, once a CTA Type has been set on the CTA, it cannot be changed BUT Reason can be changed on existing CTAs. So, it is advangetous to tie Reasons to Type for better reporting and automation.



Timeline Activity in our Organization has typically been used for email logging from CTAs and Email to Timeline. We also have setup unique Time Activity Types for various uses - sometimes to track a singular issue or other one-off scenarios.


Thanks John, we decided to go this route. With less than 200 CTAs in the system (most of which were timeline to:dos), it's still taken me 2 hours to reach out to everyone who's CTA's I needed to adjust/delete/re-create, so I'm glad we did this now.


Reply