Skip to main content

    Idea Pipeline

    Filter by idea status

    Filter by product area

    5802 Ideas

    emiller
    emillerHelper ⭐️

    Change Best Answer label from "Solved" to "Answered"Closed (Won't Do)

    Please change the best answer label from “Solved” to “Answered” or allow us to configure the word we want to use.  The word “solved” is counterproductive to running our community as a peer-to-peer forum and not an official support channel.  Product break/fix issues are often reported but cannot be “solved” via the community.  It is important to us to be able to mark official employee responses as a best answer as they do represent the best advice we (Marketing team) can provide in that forum.  Our members frequently complain about the “Solved” label and the negative sentiment it generates could be easily avoided with a simple label change.Examples of “best answers” that we want to mark:Referring a customer to support when the issue they brought up cannot be addressed via the community, sometimes with guidance around the best way to expedite their case Confirming that a known issue exists and will be fixed soon. We don’t always have the ability to come back and post when it is fixed. Confirming that a product gap exists (feature not available), with or without a workaround.  When the answer is that we have passed along their feedback to the product team, members complain that it should not be marked “solved” until we add the feature they want. Providing advice, help articles, etc as a starting point when the customer may still need further assistance from support We need a best answer to reflect the outcome of the question and not the outcome of the issue that is the subject of the question since most of the time, the issue is resolved via other channels.

    sydney.bennett
    sydney.bennettContributor ⭐️⭐️

    Error Notices - Admin Self-HelpNew Idea

    Over the past months, we have run into a few separate issues that required us to create a ticket over topics that I feel should’ve been fixable by us as the admins. My request/improvement is to increase the error notices or the context provided to Admins regarding errors. The first example is regarding uploading an email to Timeline, the subject was the same as another post in the same account’s timeline, giving the very vague error message of “Unknown Error”. Requiring support to have to come in and tell us what that Unknown Error was. The second example, when wanting to set up the Connector for Zendesk to get ticket info into GS. We received multiple jobs failing notices stating "error occurred while fetching object," we had multiple tickets open on the topic, just to find out that Zendesk only allows 50 records per API call. Something that is a clear answer but not communicated to the Admins at all. Lastly, we ran into a major data discrepancy issue with PX data in CS, using the Daily Aggregated data. It is NOT clearly communicated that the data in that record is only stored for 90 days. There should be some sort of clear messaging when using those Daily objects and a date field. The support team, although very kind and responsive, were unable to tell us that this was the issue (a predetermined Gainsight setting that should be easily communicated) for OVER a month. Meaning, we thought that all of our usage data from PX was unreliable for all that time.  And this is just a few examples, there are more that I can come up with if necessary. Even if this means Error Codes that GS Admins have to find and investigate, it would be a huge improvement, saving both that GS admin’s time AND the GS Support team.

    Samuel Brown
    Samuel BrownContributor ⭐️⭐️

    Segment-based component visibility changes should take effect immediatelyNew Idea

    When a component's visibility is configured to target specific segments, changes to a user's segment membership can take over an hour to reflect in what they actually see. This delay makes it impractical to build real-time, segment-driven user journeys.For example, we attempted to build an onboarding flow where verified customers are shown a modal on first visit. Upon completion, we update a profile field via the API, which moves the user into a different segment — at which point the modal should no longer appear. However, because visibility changes aren't applied promptly, the user continues to see the modal long after their segment has changed, effectively trapping them in a loop.This is impractical for us for serveral reasons such as:User experience degradation - Users who should be seeing onboarding content, upsell prompts, or role-specific guidance will instead see stale or irrelevant components. This undermines any personalisation effort and creates a confusing experience. Operational reliability - If we cannot trust segment targeting to update within a reasonable timeframe, it limits the value of segmentation as a feature entirely. We cannot build automated workflows or time-sensitive processes on top of a mechanism with an unpredictable multi-hour delay. Compliance and access control - Depending on the content being served, prolonged access to the wrong segment's components could have implications for data handling obligations, particularly if customer-specific documentation, pricing, or account information is exposed to non-customers.Reducing this propagation time — ideally to near-instant — would unlock segment-based visibility as a tool for building responsive, self-resolving user experiences such as onboarding flows, first-run wizards, and conditional prompts.