Skip to main content

    Idea Pipeline

    Filter by idea status

    Filter by product area

    6158 Ideas

    rsayedGainsight Employee ⭐️

    Reporting Capabilities Request – Stakeholders & Team Stats Data IntegrationNew Idea

    A JAGGAER Customer has the following question regarding reporting capabilities in Staircase:Is the data displayed in the Stakeholders section/Heatmap, as well as the Network and Radar tabs, also available in the reporting section? Specifically, the customer wants to create a report with two data points for each account:Closest JAGGAER relationship — the JAGGAER employee with the strongest connection to the account Best customer relationship — the customer contact with the strongest relationship on our side. If not, could you offer alternative solution for this request?Currently, Staircase AI offers two separate report types: Stakeholders (focused on customer representatives) and Team Stats (focused on JAGGAER representatives). However, there is no option to combine these two data sets. The Team Stats report type provides overall counts for emails, chats, and meetings with sentiment analysis, but only at the aggregate level for each JAGGAER representative/account owner without a breakdown per account.Could you please Help us:If it is possible to access backend data from the Stakeholder tab or Heatmap sub-tab for reporting purposes? Whether there are plans to make such data available in the reporting section, allowing for combination of Stakeholder and Team Stats data or breakdowns per account?This has highlighted that combining these data points would bring significant value to their reporting.​@bradybluhm 

    spencer_engel
    spencer_engelExpert ⭐️

    Allow more flexibility in "Load to People" ActionNew Idea

    I’m running into all sorts of issues with our Company Person data because of Gainsight’s strictness re: the Load to People action. Any other standard or custom object you load to in Gainsight allows you to choose your identifiers at will, which is great because sometimes you need that flexibility. However, with Load to People, you must first define your identifier in Administration > People, which is set to “email” as default and until fairly recently was the only identifier you could pick (yuck). Now that we can change the identifier though, I changed ours a few months back from email to External ID. However, I’m realizing that my predecessor did not even map External ID for some of our Company Person records, so I’m trying to go back and either backfill the External IDs or mark them for deletion, whichever is appropriate. Instead of just being able to change my identifier to “Email” for this one rule, I must go to Administration > People and add “Email” to the match criteria.   This is convoluted, but it’s ultimately ok because the rule does let me uncheck “External ID” as an identifier and only choose “Email,” which is necessary in this case because, again, the records I’m dealing with have no External ID and therefore that’s a useless identifier for my use case. The real problem is that for some reason when I set this match criteria, it updates all my other Load to People rules and my SFDC connector job to include Email as a second identifier. Why??  So now I’m resorted to doing one of the following once I add Email as a second identifier for this cleanup process: Quickly go in to each Load to People rule and change all the identifiers back to just “External ID” and not Email, or  Make sure I run this process during a time when none of my other Load to People jobs nor my SFDC connector job is running, then go back to Administration > People and undo “Email” as a second identifier.This all seems so overly engineered. I understand this was probably designed to help sort of protect admins/ops professionals from themselves re: Contact/Person data, but in reality it’s quite restrictive and simply does not jive with how any other “load to object” action works, including, ironically “Load to SFDC Contact.” 

    SiemensLBContributor ⭐️

    Enhanced Moderation Compliance Framework for DSA and Regulatory AuditsOpen

    Organizations operating public online communities increasingly need to demonstrate that moderation actions are applied consistently, transparently, and in alignment with their community Terms & Conditions and applicable regulations such as the EU Digital Services Act (DSA). Gainsight Community already provides several moderation and governance capabilities that help organizations manage content and maintain records of moderation activities. As regulatory expectations continue to evolve, an opportunity exists to further enhance these capabilities by providing a more structured framework for documenting, communicating, and reporting moderation decisions.Potential enhancements could include:Capturing standardized reason codes for moderation actions. Associating moderation actions with relevant Terms & Conditions or policy provisions. Automatically notify the affected user of the moderation decision and rationale. Maintaining a consolidated audit trail of moderation actions, notifications, and supporting details. Delivering reporting capabilities that help organizations demonstrate compliance during internal reviews or external audits.This would help community managers improve transparency, consistency, and audit readiness while leveraging existing moderation workflows.Proposed EnhancementIntroduce a moderation compliance and audit famework that requires moderators to select a standardized reason code whenever content is moderated and automatically logs all moderation actions.Key capabilities should include:Configurable moderation reason codes (Spam, Harassment, Privacy Violation, Illegal Content, Copyright Infringement, Off Topic, Duplicate Content, etc.). Optional free-text moderator notes. Mapping of each reason code to specific Community Terms & Conditions clauses. Automated user notifications explaining: What action was taken. Why the action was taken. Which policy or Terms & Conditions provision was violated. Information about the appeal process. Retention of moderation history and notification records for audit purposes. Reporting and export capabilities showing: Moderation actions performed. Reason codes used. Moderator responsible. Date/time of action. User notifications sent. Appeals submitted and outcomes. Business ValueThis enhancement would help customers:Demonstrate compliance with DSA transparency and notice requirements. Reduce legal and compliance risk. Maintain a defensible audit trail of moderation decisions. Improve consistency across moderator teams. Increase transparency and trust with community users. Support internal governance and regulatory reviews.

    anwesha.karmakarContributor ⭐️

    Idea: Allow Manual Selection of Primary Company for Sponsor TrackingNew Idea

    ProblemWhen a tracked sponsor holds multiple concurrent positions (e.g., a board seat or advisory role at one company while employed full-time at another), Sponsor Tracking automatically designates latest/current positions as "primary." If the sponsor leaves the non-primary company, that departure is not surfaced or flagged — even though it may be the position most relevant to our relationship with them. ExampleWe had a case where a tracked sponsor's profile showed two concurrent positions. Sponsor Tracking treated the latest company as primary and the other as secondary. When the sponsor left the secondary company, no update appeared in Sponsor Tracking, even though this was the departure we actually needed visibility into (since it was related to the customer). LinkedIn showed the change, but Gainsight did not surface it. Current Behaviour confirmed with Gainsight Support/ProductWhen tracking starts, Sponsor Tracking automatically selects the sponsor's latest/current position as the "primary" company. If a sponsor has multiple concurrent positions, only the primary one is monitored for changes. Departures from a non-primary (concurrent) position are not captured or surfaced. There is currently no way to manually select which company should be treated as primary for tracking purposes.CSMs rely on Sponsor Tracking to catch champion/sponsor departures before they impact renewals or expansion. When a sponsor holds concurrent roles, the system's automatic choice of "primary" company may not match the company that actually matters for our relationship — meaning a critical departure can go completely unnoticed until it's too late to react. Suggested EnhancementAllow users to manually designate or override which company is treated as the "primary" tracked position for a sponsor, particularly in cases where a profile shows multiple concurrent positions. This would let CSMs ensure the correct relationship is monitored, regardless of how the sponsor's profile is ordered externally.Curious whether other Gainsight admins have seen sponsor departures go unflagged because of concurrent positions on a profile. If you've hit this too, please upvote and share your example below. It will help Product team gauge how widespread this gap is.