Skip to main content

    Idea Pipeline

    Filter by idea status

    Filter by product area

    6159 Ideas

    t.nelsonContributor ⭐️

    Preserve Weekend-Aware Task Scheduling When CTA Due Dates Are Manually UpdatedNew Idea

    Current BehaviorUpon initial CTA creation, playbooks can be set up to assign task due dates relative to the CTA due date while automatically skipping weekends.However, there is a significant gap in the current functionality. If a user manually updates the CTA due date after the playbook has already been applied, Gainsight recalculates the associated task due dates without honoring the "Skip Weekends" setting. As a result, tasks can be rescheduled onto Saturdays and Sundays, even though the original playbook logic was configured to avoid weekends.Gainsight Support has confirmed this is the current product behavior.Requested EnhancementWhen a CTA due date is manually updated and task due dates are recalculated, the existing playbook scheduling logic should continue to honor the configured Skip Weekends option, just as it does during the initial playbook creation.In other words, the weekend-skipping behavior should remain consistent regardless of whether the schedule is generated initially or recalculated after a CTA due date change.Why This MattersCTA due dates are frequently adjusted throughout the customer lifecycle. Priorities change, customers request extensions, meetings move, and implementation timelines shift. Updating a CTA due date should be a routine action - not one that unintentionally creates invalid task schedules.Without weekend-aware recalculation: Tasks are assigned due dates on weekends, creating unrealistic expectations for CSMs and other users. Users must manually review and correct every task after changing a CTA due date, adding unnecessary administrative work. Organizations lose confidence in automated playbooks because manual adjustments are required to restore the intended schedule. Reporting and workload planning become less accurate when tasks are assigned to non-working days. For organizations with standardized customer success processes, this creates additional operational overhead and reduces the value of automated playbooks.Business ImpactMany companies rely on CTA Playbooks to enforce consistent customer engagement timelines and operational best practices. The current behavior breaks that consistency whenever a CTA timeline changes.The expected behavior is that the scheduling engine applies the same business rules - such as skipping weekends - both during the initial playbook creation and during any subsequent recalculations triggered by a CTA due date update.Maintaining consistent scheduling logic would: Reduce manual administrative work. Improve trust in playbook automation. Ensure task timelines remain realistic and actionable. Better support organizations that operate on standard business calendars. This enhancement would make CTA Playbooks behave more predictably and preserve the automation customers have already configured.

    t.nelsonContributor ⭐️

    Allow "Associated Persons" to be displayed as a column in Cockpit admin defined viewsNew Idea

    We utilize the Associated Persons feature in Cockpit and see a lot of value in associating the relevant customer contact(s) to a CTA. However, one key limitation is that Associated Persons cannot be displayed as a column in Admin Defined Views.Today, a CSM must open each CTA to see who the CTA is associated with. For organizations that create person-centric CTAs (such as onboarding contacts, low usage users, champions, or executive sponsors), this adds unnecessary clicks and makes it more difficult to prioritize work.It would be extremely valuable if Gainsight allowed Associated Persons to be selected as a column in Cockpit Admin Defined Views.Potential benefits:Allow CSMs to immediately identify which customer contact a CTA relates to. Improve efficiency by reducing the need to open CTAs just to identify the associated person. Increase adoption of the Associated Persons feature by making the information visible where CSMs spend most of their time. Better support person-centric workflows such as onboarding, adoption, renewals, and dormant user outreach.Possible enhancements:Display the primary associated person by default. If multiple people are associated, display the first person's name followed by "+X more" (for example, John Smith +2). Allow filtering and sorting by Associated Person within Cockpit views.As Gainsight continues to expand person-centric capabilities, surfacing Associated Persons directly in Cockpit would make the feature significantly more useful for day-to-day CSM workflows.

    DannyPancratz
    DannyPancratzVIP ⭐️⭐️⭐️⭐️⭐️

    New Primary User Role: Staff (Non-Admin)Released

    While non-admin Staff user roles can be somewhat accomplished with custom user roles, it’s not a perfect solution for segmenting the analytics or filtering topics/users by role in Control. The reason? All custom user roles also have to have a primary user role and the primary role is “leading.” Therefore, your custom “staff” or “employee” user role is likely to also be either a “registered user” or “superuser” primary role. This gets in the way of the utility for analytics and filtering in control. You might want to filter by posts from non-staff registered users or non-staff super-users. In particular, the helpful “answered by peer” metric in the Success Dashboard would be more valuable if peer could mean “non-staff.” That would really indicate the self-service value of community members answering each other’s questions, versus staff. Given that Moderator and Community Manager roles count against seats on the licenses (and that all staff do not need this admin access), we’re left without a way to filter out non-staff registered users. (Unless you took the pains to assign an additional custom user role to every non-staff member that signed up). If there were to be built, my recommendation would be:Posts avoid spam detection (like superuser role without the mark answer ability)  Option to automate users with an email with a specific domain to be auto-assigned this role