Skip to main content

    Idea Pipeline

    Filter by idea status

    Filter by product area

    6159 Ideas

    dcassidy
    dcassidyHelper ⭐️⭐️

    Churn Save Event DetectionNew Idea

    I've raised this during Office Hours and wanted to formalize it as an official idea.Staircase already does excellent work surfacing Churn Risk signals, Churn Notifications, Extremely Negative Messages, and Highly Positive Messages - all high-value events that drive action across CS, Sales, and Leadership. I'd like to extend that framework with a discrete "Churn Save" event.The ask: When Staircase detects a customer who was previously flagged at elevated churn risk (or even churn notification) and subsequently shows recovery or renewal signals, surface that as a named, trackable event in the platform.Why it matters:CSM-level: Gives individual contributors concrete, timestamped evidence of impact to bring into performance conversations and 1:1s — no manual documentation required. CS Org-level: Enables CS leadership to aggregate and report Churn Saves as a measurable outcome alongside ARR retained, rather than relying on anecdotal accounts. Executive-level: Provides ELT and C-Suite a defensible, data-backed metric for CS ROI — particularly relevant given current pressure on every org to demonstrate clear business value.This builds naturally on existing Staircase detection logic and would give the platform a closed-loop view of the churn lifecycle: risk identified → intervention triggered → save confirmed.Interested to hear whether others are tracking Churn Saves manually today and what signals you'd want Staircase to use to confirm a save event. 

    james_dahlgard
    james_dahlgardContributor ⭐️⭐️

    Feature Enhancement Request: Group-Based Account Access Provisioning in Gainsight CSNew Idea

    Feature Enhancement Request: Group-Based Account Access Provisioning in Gainsight CSSummaryPlease add support for group-based account access provisioning in Gainsight CS so admins can assign users to reusable groups and provision account access at the group level instead of managing account visibility one user at a time.Current LimitationToday, account-scoped access is administratively heavy when multiple users need the same access pattern, because access has to be provisioned and maintained user by user. From an admin perspective, this does not scale well for partner teams, regional coverage models, overlays, or any scenario where users should inherit the same account access pattern.This is especially important for use cases where users must only see the specific customer accounts they manage and have no visibility into the broader account list.Requested EnhancementPlease provide a native way to: Create reusable user groups or access groups within Gainsight CS Assign a defined set of accounts to a group Add users to that group so they automatically inherit access to the accounts in scope Remove users from that group and automatically revoke inherited account access Support different access levels by group, such as view-only vs edit access Preserve least-privilege boundaries so users cannot browse or search accounts outside their assigned scope. Why This MattersGainsight appears to already support account-level isolation as a control, and that control is critical for secure segmented access models. However, when that access model must be maintained manually one user at a time, it creates unnecessary operational overhead and makes the model harder to scale consistently.For example, in our environment we need scenarios where a subset of users should only be able to work specific managed accounts, while still being restricted from admin functions, bulk export, connectors, API access, Journey Orchestrator, and broad report-building capabilities.Example Use Cases External partners or contractors who manage only a subset of customer accounts Internal teams that should only access named books of business Regional or segment-based user cohorts Temporary project teams that need access to a shared subset of accounts Future-state permission models where access should be managed by role + group membership rather than repeated manual account assignment Business ImpactA group-based model would: Reduce admin time and repetitive manual provisioning Improve scalability as user counts and segmented access needs grow Lower the risk of inconsistent or missed access assignments Make onboarding and offboarding easier Better support secure account-level isolation for partner and segmented-access models Desired OutcomeWe would like Gainsight CS to support a scalable, admin-friendly permission model where account visibility can be managed through reusable groups instead of requiring one-by-one user provisioning for the same account set.