Skip to main content

    Idea Pipeline

    Filter by idea status

    Filter by product area

    6158 Ideas

    dayn.johnson
    dayn.johnsonVIP ⭐️⭐️⭐️⭐️⭐️

    New Dynamic JO Should Have Multiple Queries (just like older advanced JO)Discovery

    This idea is very similar to this post by @alizee made during the beta period for the new dynamic JO.As the title says, there is a very popular use case for having multiple queries within a single JO program: multiple queries allow us to have a much higher level of control over the time different audiences are brought into a program, without having to calculate and rely on wait steps (and trust them not to misfire).Most of our programs in the advanced JO have multiple queries (usually three): Americas, EMEA, and APJ. We use the Global Region field to determine the send time for those recipients, as neither a timezone field nor a billing country are reliable methods of determining when to send an email, and having a CSM emailing a client in the middle of the night doesn’t lend to the idea that the CSM is emailing them.We also have some programs where we have slightly different audiences (standard support clients, premium support clients) receiving monthly check-in emails, and each of those audiences uses a different query, but is still part of the same program. Bringing both of those audiences into one program and then having to filter through conditional evaluate steps will further complicate things.We prefer to use queries in our programs to have a higher level of control over the audience and the send time. Please consider allowing us to include multiple queries, just like we’ll be able to use multiple CSVs.

    bradley
    bradleyExpert ⭐️

    Staircase: Add Severity Indicator on Chrun Risk Signal InsightNew Idea

    Today when you get an alert for a churn risk signal from Staircase, there’s no real gradient on how serious the risk is. A small but potential risk would show up the same as a very high risk (up until the point where it becomes a churn indicator at least). It’s effectively binary.The AI Risk analyst for the account has a risk level - but this is an account level metric and not a per signal score. And, even though looking into the Risk Reasons surfaced by the “agent”, each individual one has a “Severity High/Medium/Low” that is not translated to the Churn Risk Insights.General proposal:Include a *reportable* severity number/label for each Churn Risk signal Number vs label likely isn’t terribly important, but thinking about ST>CS workflows, there is already a High/Medium/Low/Critical framework for CTAs, so following that could be a good start.It’s critical this is reportable, as the use cases aren’t purely informative to CSMs/Leaders, but operational:I may have a Risk Alerts channel but I only want to fire the highest band of alerts there. This is only possible if this is an attribute of the signal. I may want to create a CTA, Playbook, Report, or some other automation off of this data, and report by severity and/or only for certain bands. This would again only be possible if this is an attribute of the signal rather than only available in the UI. Having a threshold could even let organizations suppress the lowest grade in platform in general, though this wouldn’t always be advised. This could also open the possibility of re-surfacing a slightly older risk as increased in severity, rather than a whole new signal. New evidence, same signal? Higher severity, now it gets attention.In general, I think this would go a long way towards users - especially executives who typically are the deciding voice in signing up/renewing contracts - trust of the system. Right now, all risks are equal, so Staircase (possibly rightfully so) hedging on making a risk notification on a low grade risk looks the same as an all hands on deck issue. When those are compared side by side, the low grade risks look more like mises.cc ​@bradybluhm I have a particular example in mind, but would redact it to the point of uselessness posting here, but have provided the feedback to our account team.