Skip to main content

    Idea Pipeline

    Filter by idea status

    Filter by product area

    5890 Ideas

    mattmarcsmith
    mattmarcsmithHelper ⭐️

    Enhancement to Auto Log Email to Timeline featureNew Idea

    Hi all,Looking to request a further enhancement to the released feature:Looking over the Help Docs for this feature (https://support.gainsight.com/gainsight_nxt/Timeline/02Admin_Guides/AI_Follow-Up_Admin_Guide#For_CS_and_Staircase_AI_Customers), it looks like it cannot fulfil our exact requirements.Scenario: Currently we log ALL of the organisation's emails into Staircase and determine which users can see the detail of all the comms by setting the roles correctly (i.e., User, Manager, or Admin). A User for example can see details of time, subject, recipients, sentiment and lifecycle tags for all emails, but cannot see the email body. That way if a significant event is tiggered (e.g., Extremely Negative Message), they can see who the email was sent to and reach out for more detials and offer assistance, but still retain privacy.Issue: It seems that the only way to determine what emails are synced to Timeline from Staircase is by using AD groups. We still want ALL emails logged in Staircase, but I don’t see a way to specify a subset of users (e.g., CSMs only) and have only their emails synced to Timeline. As Gainsight doesn’t have a similar comms visibility setting as Staircase, users would be able to see the body text of ALL comms on Timeline and we definitely don't want that!Proposed Solution: If Gainsight can have settings on its end to be able to specify on the UI which users emails can be synced to Timeline from ST (e.g., CSMs) then this will be a good baseline option. Alternatively, having a similar permission setting as Staircase so all comms can be added to Timeline, but seeing the body text depends on a user permission would also work.

    alizee
    alizeeVIP ⭐️⭐️⭐️⭐️⭐️

    Force Update Gainsight HomeNew Idea

    Hi allReferencing this question: And because:[SPOILET ALERT]: we can’t force update Gainsight Home Identifying the rogue users is overly cumbersome  Asking support to force remove dependencies is really a waste of Support’s resources In what universe did it: Make sense for inactive users to create dependencies on Gainsight Home (especially where we can’t delete such users)? Make sense for active users to be stuck with old reports and old data → at best, it makes sense for them to decide if they want to see a report or another, but if a report is removed, it must be removed for them as well!  Make sense to not be able to force update layouts to all users: Notification settings for GS Home | Gainsight Community  (no, logging as them to force update Gainsight Home isn’t an option as figuring out who the rogue users are is cumbersome and chasing them to update is equally not helpful I’m turning the above question into an idea so we can get the upvotes going (for which I take 0 credit) but it needs to change:Admins must be able to force updates to our chosen users, groups of users or all users at any time.  Inactive users, when inactivated, if they have created some dependencies through any form of customization, should be updated in such a way that no dependencies remain.  Because currently, what we’re experiencing is this: Gainsight Home | /ˈɡeɪnsaɪt hoʊm/ | (abbr. GS Home)noun1 : Where admins must embark on epic quests to remove dependencies from the ghosts of deactivated users.2 : A feature that traps end-users in a time capsule of potentially outdated data. ThanksA

    darkknight
    darkknightExpert ⭐️

    CS: Remove or Change Copilot Personalization Agent dependency on Gainsight Home filtersParked

    THE PROBLEM:Today, when users ask Copilot (especially in Slack) questions like “my portfolio”, “my companies”, or “my upcoming renewals”, results are strictly scoped by the user’s current Gainsight Home filters — but that dependency is not obvious to end users. This can cause “no results” answers even when relevant accounts exist (example: user has a Renewal Date filter set to “next year,” so end-of-month renewals disappear).  Gainsight docs confirm that portfolio queries rely on filters configured in Gainsight Home., however,end users rarely read documentation messaging like “filters haven’t been set up” in Copilot responses can be interpreted as an admin/config problem even when filters exist — they’re just currently restrictive.  plus, not every customer and/or persona leverages Gainsight Home (think Sales account owners who don’t work in Gainsight as their primary system of record)Enablement shouldn’t be a substitute for intuitive functionality.THE NEED:STRONGLY PREFERRED: When Copilot sees “my portfolio” intent, it should first attempt to resolve “my” using User Lookup fields on the Company object, such as:CSM / Account Owner / TAM  Any org-defined “Owner” lookup to GS User (including custom fields)If a match exists, Copilot uses that ownership assignment to scope results (optionally allowing persona selection like “my renewals as Renewal Manager” vs “my accounts as CSM”).ALTERNATIVE: If that’s completely impossible (which I cannot fathom it is) then at a minimum allow admins to define portfolio ownership logic in Key Definitions, and make the portfolio resolver:Check Key Definitions first Only fall back to GS Home filters if no Key Definition existsKey Definitions are explicitly designed to provide standardized business data/instructions so Copilot responds consistently and contextually.

    Samartha B SContributor ⭐️⭐️

    Limitation & Enhancement Request: Better Support for Pooled CSM Models in Group Send FeatureReleased

     We currently operate a pooled CSM model for SMB customers. In this setup, accounts are owned by a generic CSM user rather than individual team members. CTAs and customer engagement are dynamically managed by individual pooled team members.This operating model works well for high-volume SMB account management where multiple CSMs collaboratively manage a large number of accounts. However, we are seeing limitations with the current Group Send functionality being unusable for pooled CSMs in Gainsight.Current LimitationPeople Tab Visibility on Home Page for ‘Group Send’ featureIndividual SMB users are unable to view contacts in the Home Page > People tab, which is where users select contacts to send emails to from the Group Send feature. Since these users are not configured as the actual CSM on accounts, they cannot access the relevant contacts because ownership resides with the generic pooled mailbox/user.As a result, pooled SMB CSMs are unable to effectively use the Group Send feature — even though this feature would arguably be most valuable for them, given they often manage hundreds of smaller-scale accounts simultaneously.  Enhancement RequestIt would be extremely helpful if Gainsight could better support pooled CSM workflows by enabling capabilities such as Group send features to be usable by pooled models as well:This would significantly improve adoption and usability of Group Send for organizations operating at SMB scale using pooled customer success models.