Provide admins with control over in-app messages or the ability to disable them

@tyler_mcnally As you can see from some of the other comments in this thread, this does create challenges and problems for customers who have dedicated admins. I understand that you’re a SaaS business trying to drive adoption and how especially critical that is in the current climate. I also get that not all of your customers have dedicated admins that own the strategy, design and communication stream (tho I’m willing to bet that most of your larger customers do, and I wouldn’t think you’d want to do anything irritate them).

In your opening statements, you said Gainsight intends to find a “balanced” approach to announcing new features, but the rest of the message seemed to double down on the one-sided notion that “For users/companies who would benefit from using a new enhancement of a feature, they can only advocate for improvements when they know it exists.”

May you understand and acknowledge that a more nuanced approach may be needed?  Is there not a way to filter these in-app messages for customers that have a dedicated admin vs. not? At an extreme minimum, would it be possible to notify customer admins of the intent to notify end users and the targeted messaging so we can at least be prepared and try to get ahead of it? 

Appreciate the response from Gainsight here as to their acknowledgement of how this specific announcement wasn’t rolled out well, and their plan forward. But it seems like they’re not listening to the primary complaint of their admins - their core users and biggest advocates. 

Several people have responded with how much of a headache this presents to admins who typically support several 100s of CSMs, when Gainsight makes the decision to push new *paid* feature announcements in app to end users. I can’t think of any other platform - not even Salesforce - that I, as an end user - get product and feature announcements for, because I’m not the person that has the relationship with the solution - the administrators are, and trust that our administrators are staying on top of new features and functionality given our business goals and objectives. 

It’s one thing to announce features that get rolled out to all users without admin configuration, but anything that an admin has to turn off to enable should be limited as there’s likely a reason an admin has or has not decided to, and to bypass them straight to the end user only worsens the admin experience.

I don’t think anyone is arguing that communication shouldn’t be sent out. I think the core issue here is “right message, right place, right time” as well as understanding the relationship that Gainsight Admins have to their business and to Gainsight itself. The approach of spamming all users at every business falls flat demonstrating a good understanding of these areas.

An admins sole job isn’t just to turn features on when they launch, nor are they ignorant of what the product does. We have our own roamaps, teams asking things of us, and hurdles we have to go through to get something out the door.

Sending an alert to users to ask admins to turn a feature on is no different than the Gainsight CSM sending an email copying our CS org saying “hey why haven’t you turned this on? Did you even know about it here’s a link for more!” (which is a real thing that has happened). All it does is send a message to our users that their Admin isn’t doing their job, and that the job they should be doing is trivial at best.

We all want the same thing: the best experience for our end users. But we aren’t all going to get there the same way at the same time. All we’re asking for is some flexibility and input into messaging so the vendor and business partner whose product we enable at our companies doesn’t kneecap us from doing our job effectively, and subsequently eroding the trust of our users in us. Does that sound like a reasonable ask?

I’d like to add my voice to the chorus of frustrated GS Admins here.

The decision to send a message out that tells our CSMs to “Tell your admin to turn this on!” resulted in several questions that we were not prepared to answer - painting us in a negative light. 

We reached out to our GS CSM and got a quick response, but ‘one possibility’ was to ask our users to turn off notifications in settings. She was trying to assist, so this is not a dig on her, but that doesn’t make us look any better - in fact, it makes us look as if we are hiding things from our end users. 

This isn’t the way to gain favor with the people who champion your product. 

 

we need this feature too

Not sure when this got set to “Not Feasible” but you’re going to have some perpetually irritated admins out here if things like this continue to intrude on our workflows and processes, and I don’t think you want to alienate your admin base.

Somehow hadn’t signed this petition, but adding my voice to it. This needs to stop. You are creating disruption. And I reiterate that it’s not because a tenant has all features turned on that it’s a healthy tenant / deployment. 

I’d be keen on understanding whether now being on the side of a customer deployment has changed your perspective on the matter, ​@tyler_mcnally?

​@alizee sadly preaching into the void I’m afraid:
 

​@alizee sadly preaching into the void I’m afraid:
 

 

I know 😭 but this desire to dictate how we roll out features at our respective organizations is so shocking that I still felt the need to express my utter disagreement.