Just because we have turned on a feature doesn’t mean that Gainsight knows exactly how we’re using it. How do we know that the guidance Gainsight will serve up on these features don’t contradict how we’ve instructed our uses to use them?
There's more than one way to use Gainsight. Gainsight stepping in and just assuming we’re using features their way has the potential to confuse users and likely screw up adoption. Plus, sometimes an enabled feature is intentionally not in use. How would Gainsight know the difference?
Not all customers are the same can't be all put into one basket. Gainsight’s idea of the best way to do things is limited to Gainsight’s “in the bubble” perspective. We face challenges that Gainsight does not, because their entire company is “all in” on CS. We have to curate and roll things out a certain way at a certain time.
Some Gainsight customers who are less complex and admins less experienced may welcome the in-app guidance for their users, but for those with more complicated processes/workflows and experienced admins/enablement teams must have the ability to opt out of this.
Please stop making our jobs harder than they already are.
Page 2 / 2
@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”
Weheard 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.
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.
System Email TemplatesExample: Internal Enablement Email sent to a SMALL handful of users
Thank you to everyone who registered for the upcoming session, we’re looking forward to a great discussion.
To make the conversation more collaborative and interactive, we’ve updated the format from a Zoom Webinar to a Zoom Meeting. This change will allow for greater dialogue, engagement, and participation among attendees.
For those who registered, I’ve also sent an email with the updated meeting details. However, to ensure everyone has easy access (including anyone new who’d like to join), please find the meeting information below:
@victoria_peeker_barry @romihache can you try again? Not sure what happened but I updated the links and they appear to be working for me now.
As a reminder for everyone (in case the calendar links are not working) the session is scheduled for tomorrow, October 30th at 7:30am PST.
@victoria_peeker_barry @romihache can you try again? Not sure what happened but I updated the links and they appear to be working for me now.
Nope 😣 This is the error I get for Google Calendar
But the Zoom one seems to be working, I’ve added a manual event in my Calendar with that link
Quite frustrating and I’m sry for the experience! I’m hopeful all of this will be worth it with a format designed for open dialog.
same - I added it manually
Unable to make the session today due to illness but I want to reiterate that admins MUST have the ability to opt-in to any and all in app notifications. Anything other than this creates significant hardship for admins that already have a defined and robust enablement process.
And a big 👎🏻 to the suggestion of leveraging system email templates for this. Managing journeys and templates is already complicated enough without adding more to it. Most of us manage the entire platform, not just JO. We need to make admins jobs easier not harder.
@darkknight I’m sorry to hear you won’t be able to join today as I was looking forward to your perspective in the discussion.
I understand your point around admin control and the need to minimize additional workload. I’m currently exploring an opt-out preference experience that would allow admins to manage in-app engagement settings directly. The current concept includes an in-app dialog prompt to capture preferences, with ongoing accessibility through the KCB for updates at any time. While this isn’t finalized yet, I wanted to share that we’re actively working on a solution informed by feedback from this thread.
Thank you for taking the time to share your thoughts. Wishing you a quick recovery.
If you ever had a profile with us, there's no need to create another one. Don't worry if your email address has since changed, or you can't remember your login, just let us know at community@gainsight.com and we'll help you get started from where you left.
Else, please continue with the registration below.
