Skip to main content

I know lots of Gainsight customers were clamoring for the ability to select the Activity Type when logging an email through Gainsight Assist.  I do not dispute this may have been a handy feature had it been properly executed.

However, it seems this was released too quickly and with absence of thought regarding the downstream impacts:
 

  1. Users can now choose an Activity Type, but they cannot fill out any custom/required fields associated with the type. This doesn’t save the CSM any real time/effort as they still have to go into Gainsight and edit the entry.
  2. And if they don’t go edit the entry, custom fields get logged with ‘--’ (including required fields) which exacerbates dirty/inaccurate data issues.
  3. Additionally, a custom/new Activity Type is really only necessary when there are data capture requirements that warrant custom fields on the layout for a single specific use case.  However, now that users can select Activity Type (but not any other field values) it is more difficult to make that argument and will result in a bloated list of Activity Types that could otherwise have been more streamlined.
  4. Similar to this idea, there may be Activity Types that are reserved for very specific processes that we do not want users to select through GA. This can also exacerbate dirty/inaccurate data issues.  Enablement and documentation only get you so far - a common end user thought seems to be: “if something is possible, then it must be acceptable.”

 

Agree with this. I’m honestly scared to check our data since this was rolled out. We have several activities with required fields that I suspect are not getting filled in now as @darkknight points out. 
 


Agree with this. I’m honestly scared to check our data since this was rolled out. We have several activities with required fields that I suspect are not getting filled in now as @darkknight points out. 

 

My head is spinning, can’t believe that mandatory fields weren’t included in the QA process. This is madness


I am part of product team and we are working on the feedback we are getting.

Bringing more fields in plugins is part of the roadmap and we will work on it in upcoming quarters but no ETA for now. 

We have a VCAM scheduled to understand end user’s use cases and hear feedback, The Link is here

We are working on reducing clicks while logging a mail-in compose screen and have a prototype to show. Your Inputs will help us.


Hi @Ritika Jindal 
I’m not a CSM but I can tell you from the admin side that this is a headache. On the one hand we have to go activity type one by one to identify the mandatory fields. And then, fish the invalid entries from a report… No way to streamline this process, it’s an effort almost 100% manual.

On the other hand, all the issues that this can cause downstream:
For example, a timeline entry that has a mandatory field where the user chooses a value from a picklist. And a dependent rule which picks up those records with a case like “if sthis mandatory field] equals X, do this, else, this other thing”. Now, those entries qualify under “do this other thing”. Unintentionally we can have entries flowing to that else scenario that can vary from triggering a CTA to a CSM, sending an email to a customer, writing in an object, updating fields…

I was supper happy to see the capability to choose the Company, it’s something that we have been waiting for a long time (

) but the added “choosing the activity type” with all the issues flagged by Jeff have the potential to cause a disaster. 
Honesty, I’m afraid to think about all the potential implications and I personally think that until those issues are addressed, the update should be limited just to choosing the Company and keep logging the entries as emails.
Thanks,


I concur with @romihache and will be more direct:

@Ritika Jindal this recent change allowing users to select the Activity Type needs to be reverted until we have the ability to dynamically expose the required fields depending on the Activity Type selected (at a minimum).  

As I note above, the recent change causes more problems than it solves. We cannot live with this gap for “quarters” to have the additional functionality. 

I understand this is a commonly requested feature by both admins and CSMs, but frankly speaking Gainsight did not take this feature out to its logical conclusion and appears to have been oblivious to the administrative and data implications that this would create. It should not have been released without ensuring required fields would also be surfaced.

And I’m not really sure why a VCAM is needed. This should be a very self-evident and logical issue to address. If you have mandatory fields, users should be able to complete them through any avenue by which Timeline entries can be created.

cc: @jake_ellis 


I am part of product team and we are working on the feedback we are getting.

Bringing more fields in plugins is part of the roadmap and we will work on it in upcoming quarters but no ETA for now. 

We have a VCAM scheduled to understand end user’s use cases and hear feedback, The Link is here

We are working on reducing clicks while logging a mail-in compose screen and have a prototype to show. Your Inputs will help us.

@Ritika Jindal See above thread for input on what folks need 🙂. We shouldn’t enable ways for users to bypass required fields - respectfully, this should not have made it out of the design phase as is. 

I understand the concept of an “MVP” launch, but there needs to be some thought into what the end state would look like, and what an acceptable minimum would be to be viable.


I’m really surprised that Gainsight gave no apparent thought to required fields on different activity types. They are REQUIRED for a reason. The fact that there is no ETA and is quarters out is the biggest oversight - it truly shows that required fields were not even in the thought process of this feature development and additional fields were seen as a nice to have down the road. You might even get some feedback back from CSMs saying “we love this - so streamlined!” (translation: I don’t have to fill in any of those required fields anymore!). Meanwhile us admins are explaining to all of the leadership that because of this change that Gainsight has decided to make their reports are going to be skewed and inaccurate because we can no longer enforce getting the data we need.


You might even get some feedback back from CSMs saying “we love this - so streamlined!” (translation: I don’t have to fill in any of those required fields anymore!). Meanwhile us admins are explaining to all of the leadership that because of this change that Gainsight has decided to make their reports are going to be skewed and inaccurate because we can no longer enforce getting the data we need.

 

100% - Not only that, but there’s a good chance that as a result of this either:

  1. CSMs will be asked to go back and edit their entries (if someone leaves before correcting them then we’ll just never know what the right info was!) which completely negates the “yay so streamlined” confirmation bias feedback from CSMs anyways.
  2. The tool will get blamed, and will be another reason someone might be asking “why are we using this?”

Or both.


You might even get some feedback back from CSMs saying “we love this - so streamlined!” (translation: I don’t have to fill in any of those required fields anymore!). Meanwhile us admins are explaining to all of the leadership that because of this change that Gainsight has decided to make their reports are going to be skewed and inaccurate because we can no longer enforce getting the data we need.

10000000000 x this!

This is exactly why going straight to CSMs for input is not the brilliant strategy GS thinks it is. They have zero insights into systematic dependencies.

Admins will always - ALWAYS - have the CSM/end user perspective in mind when making requests and advocating for changes. They are our stakeholders.  We know better than Gainsight what they need and how they need it.


I am part of product team and we are working on the feedback we are getting.

Bringing more fields in plugins is part of the roadmap and we will work on it in upcoming quarters but no ETA for now. 

We have a VCAM scheduled to understand end user’s use cases and hear feedback, The Link is here

We are working on reducing clicks while logging a mail-in compose screen and have a prototype to show. Your Inputs will help us.

Hi @Ritika Jindal - I’m confused how this is not being fixed ASAP? Why are we allowing a way for Timeline entries to be created where the user cannot fill out the required fields? Having the user create the entry vie Gainsight Assist and then go into Gainsight to correct the TL entry is not an acceptable interim solution.


For all the conversations we have that a tool like Gainsight should bring to life a process that’s well thought out and effective, introducing a way to bypass required fields is a miss.

CS Ops and Gainsight CS experts spend significant energy building processes and workflows which are carefully crafted, then expertly built in Gainsight CS. To have those broken by a planned change (hat tip @romihache for detailing the pain), with no definitive timeline (pun quite intended) to make an additional change is unsettling.

Hearing there’s a VCAM, in my humble experience, is not a reassuring message if I have broken processes and workflows. What I interpret, fairly or unfairly, is that we’re months away from updates here. As a CS Ops expert, I’m left wondering

  • Must I re-enable my CS team on how to best utilize Gainsight Assist? Or must I re-enable my CS team to update Timeline entries now missing required fields?
  • Must I build new Reports to document the impact of the data quality deterioration introduced by the Gainsight Assist change?
  • Must I re-build workflows, in the form of Rules or Data Designers or Scorecards or Programs to account for records with required fields not having values in those fields?

This is a change management “miss”, and I’m joining the chorus, currently composed of some very long-time, very loyal and very experienced Gainsight experts, that help arrive sooner rather than later.


Well said @matthew_lind 

I will add that, while the majority of the focus and urgency in the comments is rightly on the missing required fields, the fact that not every Timeline Activity makes sense to be logged via Gainsight Assist and admins must have the ability to “hide” certain types from GA should not be overlooked or forgotten. That also can affect data integrity as noted in the initial post.


Hello all,

We sincerely apologise for the inconvenience caused by our recent changes in GS Assist plugins which may have affected your workflows.

We value your feedback and are actively working on improvements.

To address your concerns, for now, we’ve introduced a tenant level feature flag which when disabled can revert back to the previous functionality. 

Currently, it can not be configured by admin and you will have to reach out to support, and create a ticket to get it disabled.


@kstim for awareness! ☝️


For context, while we understand that not everyone is satisfied with the updates, we’ve also heard from customers who are happy with the improvements. The goal is to balance the needs of all our customers so after considering all perspectives, we made the intentional decision not to roll back the changes for everyone. Additionally, we want Admins to be able to manage how and when they communicate any reversions to their end users.


@Ritika Jindal @sshroff 

I was told by my CSM that adding required fields to the selector in Gainsight Assist is not presently on the roadmap. 

To clarify - admins were not asking for the ability to turn off the Activity Type selector because we/our users don’t need that ability - we desperately need that ability, however for most of us it’s not usable and contributes to data problems without having the required fields available.

IMO this should be a top roadmap priority as it will improve the end user experience significantly. 

 

In tandem with that item, this should also be a top priority.