Skip to main content

    Idea Pipeline

    Filter by idea status

    Filter by product area

    6159 Ideas

    Bhanu prasadGainsight Employee ⭐️

    Feature Request: Make Health Score / Product Score Available as a Standard Filter Across PXNew Idea

    Hi Team,I would like to submit a feature request based on a limitation that has been reported by multiple customers and is impacting their ability to use Health Score effectively within Gainsight PX.BackgroundThe Health Score (also referred to as Product Score) is available under Administration > Attributes and can also be viewed in Account Explorer. However, this attribute is not available as a filter or targeting option in several important areas of the product.Current LimitationAt present, customers cannot use Health Score or Product Score in the following areas: Audience Explorer for creating user or account segments Engagement Audience Rules at the account level Analytics dashboards and reports Email engagement triggers or automation rules Although the score is available in the platform, customers are unable to use it to build audiences, target engagements, or automate workflows.Business ImpactHealth Score is one of the most important indicators customers use to identify accounts that may need attention. Since it cannot be used as a filter or targeting attribute, customers are forced to perform manual work instead of creating automated workflows.One common use case that is currently not possible is: Automatically show an in-app guide when an account's Health Score falls below a defined value. Automatically send an email when an account's Health Score drops below a specified threshold. Build audiences based on different Health Score ranges for proactive customer engagement. Filter analytics to understand the behavior of low-health or high-health accounts. These are common customer success and retention workflows, but they cannot be achieved today because Health Score is not available in audience rules or engagement conditions.Current WorkaroundThe only available workaround is to: Open Account Explorer. Filter accounts using Product Score. Export the results as a CSV file. Upload the CSV as a CSV Segment. Use that segment for engagements. While this works, it requires manual effort every time the data changes. It is not scalable, is not real-time, and prevents customers from creating dynamic audiences and automated engagement journeys.Requested EnhancementPlease make Health Score or Product Score available as a standard filter and targeting attribute in the following areas: Audience Explorer filters Engagement Audience Rules at the account level Analytics filters and dashboards Engagement trigger conditions for both in-app and email engagements Why This Should Be PrioritizedThis request has been raised by multiple customers who want to automate engagement based on account health. Since the Health Score already exists within the PX data model and is visible in Account Explorer, making it available across filtering and targeting experiences would greatly improve its usability and help customers automate important customer success workflows.This enhancement would reduce manual effort, improve customer adoption, and enable proactive engagement based on account health.Please let me know if any additional customer examples or business use cases would be helpful. Thank you for considering this request.Thanks,Bhanu

    amasica1217
    amasica1217Contributor ⭐️⭐️⭐️⭐️

    Allow manual override/correction of AI-generated Background in Cheat SheetNew Idea

    Problem:The AI-generated company background/description feature works by prompting an LLM directly rather than pulling from a verified source like the company's website URL on the account record. When a company name is shared by multiple organizations, the AI can generate a description for the wrong company entirely — and today there is no way for admins or CSMs to correct it.Real example:For our Account A Gainsight support confirmed the AI generated a description for Account B a UK-based job-matching platform - a completely different company that happens to share part of the name. Support confirmed via Engineering that:The description is generated from general AI/web knowledge, not from the company URL or internal timeline/account data already stored in Gainsight. There is currently no way to manually edit or correct a generated description. No way exists to feed the AI the correct company URL to ground its answer.Why this matters:CSMs & leadership rely on this field for quick context before calls/QBRs — an inaccurate description actively misleads rather than helps. We already have the correct company URL/website stored on the Company object in Gainsight. It seems reasonable that the AI should be grounded in that data (or at least allow it as an input) rather than guessing from name alone. Name collisions aren't rare - many companies share names with unrelated entities (recruitment platforms, consumer apps, etc.), so this isn't an edge case.Requested solution (either would resolve this):Allow admins/CSMs to manually edit or override an AI-generated company description, similar to other editable fields, OR Let the AI generation process use the Company's website URL (already stored on the account) as a grounding input instead of/alongside name-based lookup, so it doesn't have to guess.Impact if implemented:Improves trust and accuracy of AI-generated content across the CS org, especially for companies with generic or non-unique names.

    darkknight
    darkknightExpert ⭐️

    CS: Improve AI Follow-Up/Connector Monitoring, Failure Notifications, and Troubleshooting CapabilitiesNew Idea

    A recent Gong outage caused synchronization to stop for several days without any proactive notification to administrators. The connector remained in an "active" state even though meeting data was no longer being ingested. The root cause was eventually determined to be invalidated Gong credentials following the outage, but there was no visibility into this condition from within Gainsight.As a result:• Admins were unaware that synchronization had stopped.• The connection appeared healthy despite being unable to retrieve data.• There was no proactive alerting mechanism for systemic failures.• Recovery required manual reauthentication even though the connection status never indicated a problem.• Validation of missed records required manual reconciliation between Gong and Gainsight.These gaps create operational risk and erode trust in the platform because customer-facing teams may unknowingly operate on incomplete conversation data.Even though we are currently still on the “old” Gong connector, I’ve been told by Gainsight support that the alert/notification/triage experience with the “new” Staircase-based AI Follow-Up for Gong (and other tools) still has similar gaps. Requested Enhancements1. Proactive Failure NotificationsAdministrators should be able receive alerts when:• No meetings have been successfully processed for a configurable period.• Authentication failures exceed a threshold.• Upstream provider outages impact synchronization.• A connector remains connected but is no longer successfully ingesting data.Notifications/visibility should be configurable/selectable and be delivered through mechanisms such as:• Email• In-app notifications• Slack/Teams integrations• Admin dashboards2. Connector Health MonitoringProvide a clear health status that goes beyond "Connected."Examples:• Healthy• Degraded• Authentication Failure• Provider Outage• Processing Backlog• No Data ReceivedThe system should distinguish between:• Connection status• Authentication status• Data ingestion status• Processing status3. Sync Gap DetectionAutomatically identify when expected meeting activity is not being received.Examples:• User had Gong meetings but none were imported.• Meeting volume drops significantly from historical norms.• Large processing backlogs accumulate.4. Root Cause VisibilityProvide diagnostic information directly within the product.Examples:• Last successful sync time• Last successful authentication• Most recent error• Failed meeting count• Authentication token status• Impacted usersThis would reduce dependency on Support and Engineering for common triage activities.5. Missing Record ReconciliationProvide tooling/reporting natively in Gainsight CS to identify records that should have synced but did not.Examples:• Compare source-system meeting counts to imported counts• List missing meetings• Replay processing for selected meetings• Bulk reprocess affected date ranges7. AI Follow-Up Operational DashboardFor the Staircase-based AI Follow-Up architecture, provide an operational dashboard showing:• Meetings received• Meetings processed• Meetings failed• Meetings awaiting transcript delivery• Retry activity• System-wide health indicatorsEven if the architecture is event-driven rather than batch-driven, administrators still need a way to identify systemic stoppages.Business ImpactOrganizations increasingly depend on AI-generated meeting insights for customer success workflows, adoption tracking, executive visibility, and risk management.When ingestion silently fails:• Customer interactions are missed.• Timeline data becomes incomplete.• AI insights become unreliable.• Teams lose confidence in the platform.• Administrators spend significant time performing manual audits and reconciliation.Improved monitoring, notification, and troubleshooting capabilities would increase trust, reduce support burden, and make AI Follow-Up a more robust enterprise-ready solution.

    bjoern_schulze
    bjoern_schulzeHelper ⭐️⭐️⭐️

    Privacy / Data erasure policy: Fully remove a username from the community after account removalParked

    inSided stated in their data erasure policy that when a user account is being removed - in order to anonymize a user:“no personal data is available anymore, nor in the system nor in any backup - the user record can no longer be retrieved” “their content will be left intact to avoid damage to the community - but the attached user record is now Anonymized”But unfortunately that’s not fully true. What happens:A user (in this case “Spreeandre”) registers in the community, posts topics and / or comments Other users interact with this user by quoting or mentioning them The user then asks for his account to be deleted After the account is deleted, the user’s own content is being anonymized But: The username in mentions and quotes won’t be anonymized → inSided’s claim that “no personal data is available anymore” isn’t true because it is still easily possible to connect the anonymized content to the original username (which can easily be found via Google)The reason why this happens is:The username is being inserted as a plain text so after a posting was published, the username is a fix part of the content The correct way of doing it would be to load the username from the database every time the content is being loaded → So when a change is being made (e.g. username change or user is being removed), the data will be loaded from the database and instead of the plain text username the updated “Anonymous” (or changed username) will be displayedThat’s why our proposal is:In order to really ensure the “right to be forgotten”, it is necessary to change the way the usernames are being displayed in mentions and quotes. It is necessary to pull the data from the database instead of inserting usernames in plain text.If this isn’t done, inSided customers are violating the GDPR because they don’t fully remove the identifiable user data from the platform automatically (and doing it manually by editing every single piece of content where an anonymized user was being mentioned or quoted is a very time-consuming and error-prone work around).

    Akhil GurujuGainsight Employee ⭐️

    Stakeholder marked Inactive too early — farewell email attributed to the sender instead of the actual departing personNew Idea

    Hi all,We've hit a scenario where a stakeholder is automatically marked Inactive much sooner than expected, and the root cause appears to be how farewell emails are attributed.What's happeningStakeholders are auto-marked Inactive by a scheduled (daily) job. Normally a stakeholder is marked Inactive after 90 days with no communication. However, once a farewell email is on record for a contact, a shorter 14-day silence window applies instead of the usual 90 days. The issue: the stakeholder had sent a farewell email — but the farewell was announcing another person's departure, not their own. The system attributed the farewell to the sender rather than to the person actually leaving (who was named in the email). Because a farewell was now on record against the sender, the 14-day rule applied to them. When that stakeholder then had no communication for more than 14 days, the job marked them Inactive — even though they never actually left.ImpactA still-active stakeholder gets flipped to Inactive prematurely. (As soon as a new communication occurs with them, they're marked Active again, so no data is lost — but the status is misleading in the meantime.)Enhancement requestImprove farewell detection/attribution so a farewell is tied to the actual departing contact (the person named in the email) rather than the email sender. This would prevent active stakeholders from being incorrectly switched to the 14-day window and marked Inactive.Has anyone else run into this? Would appreciate seeing this attribution improvement prioritized.Thanks!​@bradybluhm