Skip to main content

    Idea Pipeline

    Filter by idea status

    Filter by product area

    5807 Ideas

    darkknight
    darkknightExpert ⭐️

    Enable Admin to remove "Default Reason" from ANY CTA Type (including ALL)New Idea

    Under Cockpit configuration, CTA Reason, when I select CTA Type ALL there is a Default Reason (currently set to "Activity").  I am not able to remove that/set it to blank. So, for example, if I am creating a CTA and select "RISK" as my CTA Type, the Reason defaults to Activity.  Because that is the default reason for ALL CTAs.  I don’t have a Default Reason set for “RISK” type because I want end users to select one.Because this is becoming the default Reason on EVERY CTA Type, and pre-populates, end users are failing to select the correct Reason Code.  So we have dozens of Risk CTAs with the Reason Code “Activity” I asked support if it’s possible to remove the default reason from ALL and here was the answer:I would say our team has a more strict backend change policy nowadays in doing custom changes and likely we won't' be able to avoid future issues/discovery.Although we don't have a way to set it to blank, after reaching out to the team to suggest. Is it possible to create a reason called "Invalid Reason"? Then for the CTAs where CSM hasn't set it would show up in reporting that they would need to reset it to a different reason.If they didn’t notice and change it from “Activity” it’s unlikely they’re gonna change it from “Invalid Reason.”On one hand, yes, this can be viewed as an enablement issue, but on the other hand I would expect that if we don't have a default Reason Code on the CTA Type selected, the field shouldn't populate, forcing end users to select one.  Let’s make the product more foolproof.  

    darkknight
    darkknightExpert ⭐️

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

    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.

    Allow for groups to be archived/unarchivedOpen

    We utilize groups for a lot of things and I’d love to have a way to be able to archive/unarchive a group once a group is no longer needed while still retaining the valuable content in that group should it want to be referenced or resurrected later. You can think of this being similar to how a channel can be archived in Slack.This would do a couple things:it would remove the group from the overall groups list in Destination it would move the group from the main list in Control to some sort of archive list or grouping or indicate the group as archived vs. active it would retain the topics in that group should someone want to reference and also could automatically remove the members that were part of the group and notify them that it has been archived.Some examples for us:we use groups for betas. At the end of the beta, we’d like to be able to archive the group so it no longer appears in our list of groups while still retaining the topics created in that group for reference by our product team should it be needed. Today we have to instead move a bunch of topics to a hidden category, then delete the group and this is all manual work. we may create a group, then find out that it’s not delivering the expected value (e.g. a group for a city/region). It may be helpful to get it off the site, remove and notify the members, and retain the content should the group want to be resurrected again in the futureI’d see this applying to any group type - public, private, or hidden.