​@jared_block thank you for listening to us and collaborating with us.  I am looking forward to joining the community forums.  Just curious if you are considering not launching in-app guides to our users regarding functionality we may own - but have chosen NOT to roll out for various reasons

Are you able to tailor it based on what you see our teams  use?

​@victoria_peeker_barry Absolutely! We’re able to customize in-app experiences using user telemetry and profiles (like role or title). The goal is to deliver relevant, role-based content that supports our admins by reinforcing instance-specific training with contextual foundational learning.

I hope you’ll be able to join the Community Forum—I’ll share the details here once the date is finalized.

Thanks for sharing, @dayn.johnson. Good example of how complex this can get, and why being intentional in our digital strategy critical to experience we aim to deliver.

​@jared_block I will def plan on joining….I really want to make sure our users are not targeted for functionality we are not using - even if it is part of the base platform

Great callout, @Molly.McQ. That’s been on my mind as well. Coincidentally, my team and I were just discussing last week how we could create that experience for admins. It’s still early days, but it’s definitely something we aim to explore further.

 ​@jared_block Reversing this a bit:

• YOU said “We’re designing ways to tailor visibility, timing, and messaging to fit your enablement strategy, not compete with it”
• We heard you: “We may let you see it, time it and adjust the messaging, but we won’t let you turn it off”
• I heard you (not speaking for others): “We don’t trust you enough to know what will and won’t work in your environment, so this is happening whether you like it or not” 

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.

This may be cynical, but I’ve worked with GS long enough to know this dance. GS positions this as trying to help us, but this is a self-serving step plain and simple. I get that Gainsight is looking for ways to improve their KPIs, but how is giving admins another thing  to manage/monitor/be concerned about or forcibly integrate into our already complex workstreams helping us?

Gainsight is a highly customizable platform. As I stated at the outset, Gainsight cannot possibly know what features we’ve actually launched with our teams and how we have coached them to use them, therefore there is no way Gainsight can fit every individual customer’s enablement strategy. It’s just not possible. So this would be an intrusive step to the majority of mature and experienced admins.

Case in point: I saw in our Admin Slack group today an admin who I won’t name lamenting that they already saw a pop-up today for Success Plans, which they had not enabled their teams on.  

If there are admins telling you that we do not need nor want in-app guidance, then you should trust us and give us the ability to opt-in/opt-out.
 

​@darkknight I hear you and really appreciate the continued dialogue. Your perspective, and the passion behind it, are incredibly valuable as we work to find the right balance.

I hope you’ll be able to join the upcoming Community Forum; it’ll be a great space to continue the conversation together.

I want to provide a quick update on a couple of items:

The Community Forum is scheduled for October 30th at 7:30am PST. Please register HERE.

Additionally, the feedback received around a communication preference center is heard. As such, we’re pausing the deployment of new in-app engagements until we’ve established a clear process for collecting and managing communication preferences. Once that’s in place, we’ll notify the group with a link to review/update those preferences.

I appreciate the continued dialogue and look forward to seeing you all virtually at the Community Forum.

Some kind of simple per-feature preference center that admins can control would go miles towards resolving some of the internal friction and confusion that one badly-timed notification for a feature that is not deployed, or still in testing, or specifically only being deployed to a subset of users based on needs, can cause.

I understand Gainsight’s desire to drive adoption, we’re all in that game ourselves, but because the system is SO extensive and users don’t always fully grasp the total picture of a deployment’s architecture some additional control over what is advertised to them would be appreciated.

Thank you, ​@TMaier.

I want to strike the right balance between getting an admin preference center in place quickly and, over time, exploring more granular, per-feature controls for in-app experiences.

​@jared_block I want to clarify and confirm here a point that you and I discussed a few minutes ago, (after I gave you several real world examples of where in-app messaging, whether via pop-up or a passive indicator, could lead to confusion and/or disruption) which is that you do see the value and importance in giving admins the ability to choose whether or not to opt-in to any and all in-app messages and that this would be part of the preference center. 

This will demonstrate good faith on Gainsight’s part and trust in an admin’s ability to determine what is applicable to their environment and their users. It will also go a long way in engendering good will with the admin community leading to a significant increase in admin cooperation and constructive feedback in developing a broader solution. 

Brainstorming this a bit – something that could be useful would be to leverage the existing (and MASSIVELY under-utilized, from my perspective) “System” email templates that are part of every user’s tenant to create enablement emails referencing support documentation (or do something similar). THEN send a notification messages to super admins advising that a new template giving guidance around a specific feature had been created (including links to new/updated documentation we as admins might not even be aware of).

This would put the ball in our court. We could then clone that template, customize it for our intended audience, and send it via JO/Gainsight Assist/etc. as fit our needs/schedule.

The system email templates themselves are a different topic altogether, I’m just thinking through a way to share enablement messages that would give us the ability to customize the content for our users.

This would also make it easier for us to create our own enablement, focused on the features/use cases that matter most to our end users (and to different subsets of our users). Our users aren’t looking for a litany of links to page through – they want the key info pulled into a quick, high level doc and/or video overview, with the ability to go to the sources if needed.