I second this. Use cases vary dramatically and this can and will be a huge issue with our users. We try to limit enablement that isn’t useful and are quite diligent in our communications and enablement expectations for our team. We have a dedicated CS Ops function and part of our responsibility is managing change. This overstep takes that autonomy and consistency in messaging away from us. 

We should 100% be able to opt-in, but the value here is providing these metrics to us as the Admins so we can do with the info what we need to. 

Spot on! I completely agree with the need to opt out of this "one-size-fits-all" guidance.

A feature may be enabled for internal testing without it being officially announced to users or even guaranteed to "make the cut" after internal review. Enabling != Launching. Gainsight's guidance could easily contradict our internal testing instructions.

Also, to echo the point above, if we had clear access to the underlying metrics, we could better prioritize and decide on the next steps.

FYI ​@vineshgvk ​@Molly.McQ 

100% agreed with the points above and a desire for this to be an admin-enabled configuration. Some folks may want this & that is great for them, especially those at smaller organizations without robust resources.

But from my standpoint as an admin at a larger organization with multiple different CS-tiers/regions/expectations, it’s incredibly important for us to control the narrative & expectations of when a feature is enabled, how training is done & what documentation is shared with the end users. 

We definitely need more flexibility here. We often face limitations in Gainsight’s permission configuration that force us to enable features instance-wide that we don’t intend to be used instance-wide, so our internal enablement team tailors communication around those features to the teams who need to know only. 

Example: Our team is currently going through phased AI feature rollout starting with Copilot. Because Gainsight is inconsistent with data permission granularity across feature areas, we have to make new permission bundles for users to use Copilot. But from AI admin, we are forced to turn it on instance-wide. Default bundles include Copilot for Full and View licenses. We are starting this week with a “POC” group, though the feature will have to be turned on instance-wide; if users begin receiving in-app notifications to entice them to adopt the feature, we face the risk of users mis-using the application without our specific training guidelines during the rollout. Additionally, if non-CSM users who have full licenses for other fringe cases (Onboarding, for example) see that Copilot is available, they may get excited --- but it will likely cause frustration for them since a great deal of information they need for customer accounts is embedded in Gainsight from our BI tool/external web pages, not native, and in objects that Copilot can’t yet access.

What COULD work here: Admin-configurable, instance-wide “opt in/out” for communications with options at a granular feature-specific level, and an admin-configured “Default” setting. ie: “enable in-app messages from Gainsight for the following features?” 

• Cockpit - {boolean - yes/no} - {filters for user attributes to include/exclude}
• Timeline - {boolean - yes/no} - {filters for user attributes to include/exclude}
• AI Features - {boolean - yes/no} - {filters for user attributes to include/exclude}

If the “default” value is “Yes” then by default, new available features will receive notifications for users who have it enabled. If the default value is “No”, then by default, new features will be disabled until an admin updates the configuration.

Something like the above could be great. There are definitely Gainsight customers who will benefit from these notifications --- but many of us will be caused a great deal of pain from this change. 

I have been reflecting on how many of us (including me) use tools like PX or Pendo for in app communications for our own products, but do not want Gainsight to send these types of alerts. I think the main difference is the level of customization expected to make the product work at all.  Gainsight (and other tools like Salesforce) usually require an Admin to configure their tool.  Otherwise, the end users cannot get the full value of their product. If our product worked with that same level of nuance, I would not use PX or Pendo.  But since ours is pre-configured (our super users can only add new users), the messaging can be consistent.  If Gainsight worked without configuration, the same for everyone, and we all used the same language, I would not push back.  But, since they require customization, please allow those doing the customizing to maintain consistent communications.

100%, ​@darkknight.

re: sometimes an enabled feature is intentionally not in use:

Along a similar vein, sometimes an enabled feature has not been enabled for all teams with Gainsight licenses, or needs to be rolled out over an extended period. Notifying all users with access to Gainsight causes confusion.

Case in point: the new Slack AI agent. This particular feature required a very lengthy security and legal review prior to getting approval to even begin testing. During this time, we had end users who found out about the feature and submitted requests to our security, legal, and ops teams to enable the feature, despite the fact that I was already involved in the approval process. As part of the approval process, we had to validate for our legal and security teams that certain security and data control methods were in place, such as the Wildcard channel blocking option which was previously not stated in FAQs.

Bottom line:

Just because a new feature will benefit our end users, doesn’t mean we’ve had time to thoroughly vet it, get approval, and create our own INTERNAL enablement. End users see the shiny new feature and think about how awesome it’ll be. We can see the forest for the trees, but we’ve gotta chart our journey to get there in our own time. We can’t take a helicopter to get there. 🏕🚁🏔🚶🏕

Please let us chart our own Ops roadmap. It’s not the same as Gainsight’s.

I totally agree - There  are so many ways to customize Gainsight and so may “new” features are not ready for a mature organization - I really feel the admins need control of how functionality is rolled out and enabled

Gainsight that concerned about driving adoption? Give us this instead.

+1

We have different teams using Gainsight for different features. Most of these teams have systems of their own that they are responsible for updating/managing their day-to-day workflow. In some cases, part of the reason why other teams have adopted Gainsight is because we are making it simple for them to do so. If they’re asked to utilize features that are not intended for them, this may adversely impact their willingness to adopt Gainsight.

I also agree that because a feature is enabled doesn’t mean that it has been rolled out to everyone. I often have to enable features for compliance vetting, admin-testing, small-group user testing, or documentation purposes. In other cases, we might be revamping workflow, processess and communications for a particular feature in preparation for a re-launch. 

Lastly, we do not want to inundate users with communications, particularly at a time where they may have different roles to play or varied workloads. Example, a named CSM may be asked to use a feature differently than a Scaled/Digital/Pooled CSM. 

Lets not forget many features roll out as MVPs and are not ready to be used widely.  I understand that Gainsight needs feedback but we have to focus on our teams trusting the system and MVPs take away from that trust

Our adoption of Gainsight fragile as we get CSMs to adopt current features. If they get messages about new features, it will hurt our adoption. I’d love to turn off this feature so I can have them focus on using the current tools. 

+1 on all the points made above, especially anything to do with requiring IT/legal approval. 

Our users have a hard enough time knowing what to do with their day, we don’t need any additional conflicting advice on feature usage. Not to mention unwanted pop-ups that distract them from completing their work.

Gainsight: “We are going to send you less email!”

Also Gainsight: sends an email to tell us that

But in all seriousness... as a program manager for my org’s digital CS program, I found this was a really odd email to receive. The purpose of digital comms is to tell customers what they really need to know. This email was not worth the time.

+1

We turn on features to test but do not roll them out all the time. GS requires strict enablement due to how configurable the tool is and this kind of notification undermines our ability to do our due diligence

Agree with what everyone has said here. Our teams are constantly being inundated with new tools and new features, so we’re very calculated about when we introduce new things, and also provide detailed use cases specific to the org and not just a general overview so that it speaks more to how they could use it.  Adding in more noise to their day or a general description may serve to annoy rather than empower.  There are also features that just flat out won’t work for certain roles - looking at you Group Send.  So, telling ALL our users about a feature that they can’t even use seems like it would only make more work for an already overwhelmed admin.  Now, if you gave me the ability to customize the message and the audience, that would be another story.  Please consider allowing an opt out.

I’m not sure what else new I can add here, but in addition to agreeing with my colleagues above I would add/reiterate two other points:

1. Some items in Gainsight are “on” and you can’t really turn them off, even if you don’t use them. So I’d be concerned that Gainsight’s definition of “deployed” vs. what any given org would for any given feature.
2. My one slight disagreement is that I don’t think this should be an opt-out. I think this should be an opt-in. This could be an interesting feature for orgs that want or need it, but we should be able to decide if we want to join the program(s), not have to take extra steps to get out of the program(s).
   1. As a follow up to this - Gainsight is notorious for making changes and not really announcing them, so we’d have to constantly monitor if there is a new thing we have to “switch off”. Or, more concerning, things that get “switched back on” because it’s somehow different now so it’s technically a new thing (e.g., just look at reporting on Source in things like Asset usage - you have Dashboard, DASHBOARD, HOME_PAGE - all reporting. Do I have to manage toggles for all of these???)

Disagree. If Gainsight is going to start flooding my end users with in-app messages, I absolutely want to be informed before they do so that I can register my strongest opposition to it. This is exactly the type of email I want to receive from Gainsight - just not the BS marketing stuff.

Fantastic idea, ​@bradley. I’d much rather get a notification that a new feature/communication/etc. is available for us to toggle on (default state = opted out), than to be told that something will be/has been turned on, and know that we need to take action and toggle it off (default state = opted in) because our environment is now doing something we didn’t ask for.

Adding to the dogpile here. My end users have differing needs. We have a Professional Services team, a Delivery Success team, a Customer Success team, an Onboarding Customer Success team, and AI-Product (internal) specific team, After-market sales, Tech Support and more.

Each of these teams have an extremely prescriptive (and different) way of using Gainsight. None of these teams need to be bothered by more email and in-app notifications from Gainsight about irrelevant-to-them features.

That is one of the most important functions of the CS Operations team - enablement and empowerment. It is tantamount to the admins in my org that we control the messaging and narrative. We’re already herding cats, now you’re making it worse for us. 

Please, please here our pleas for this to be admin-controlled. 

One other thing to add here: We wouldn’t want our leadership/executive team to receive in-app notices or emails on how to better use the system.

Hi everyone – I’m Jared, Sr. Manager of Digital Customer Success at Gainsight.

I just want to start by saying thank you. The thoughtfulness and honesty in your feedback really came through and it meant a lot that you took the time to share it. It’s clear how deeply you care about creating meaningful, respectful experiences for your users and that passion is exactly what makes this community so special.

We also heard something deeper in your comments: that at times it can feel like we’re not fully listening. That’s fair. And it’s on us to show you that we are.

Here’s how your feedback directly shaped our thinking:

• You said: “We don’t want sales content in our in-app experience.”
  We heard you. These notifications will not promote paid or add-on features. The intent is only to spotlight capabilities you already own.
• You said: “We want more control and flexibility.”
  We heard you. We’re designing ways to tailor visibility, timing, and messaging to fit your enablement strategy, not compete with it.
• You said: “We’re cautious about anything that adds operational lift.”
  We heard you. We’re focused on minimizing noise and disruption, ensuring these experiences enhance, not interrupt your workflows.

Our goal is simple: to help you and your teams succeed…to make it easier to get real, measurable impact from the platform, guided by data and shaped together with you.

You all shared such insightful and constructive feedback that we want to keep the conversation going live. We’ll be hosting an open Community Forum discussion soon to dig in together and share ideas. Our goal is to build with you, not for you. We’ll share details on how to join the Community Forum discussion by early next week at the latest.

Thank you again for holding us accountable, for caring enough to speak up, and for being such an integral part of the Gainsight ecosystem.

Thanks, Jared; really appreciate your response and collaboration. 

Adding my two cents and speaking from an admin and ops perspective, the biggest challenge isn’t just the messaging itself, it’s ownership. When Gainsight messaging reaches our end users directly, any confusion or misalignment falls on the ops/admin team to resolve. Having visibility, control, or a simple approval step before messages launch would go a long way in keeping comms consistent and maintaining user trust.

Looking forward to seeing how this develops.

Thanks ​@jared_block – looking forward to joining this upcoming session.

It’s definitely a balancing act getting this messaging out to admins while at the same time controlling who doesn’t see something they shouldn’t (or that we don’t want them to see yet). Example: one of our former CSMs who is now in a different role – a role that has brought her more into the ops world, where she does need to be aware of new/updated features that would impact her AOR.