Hi Scott. We have 2 user roles in Gainsight: CSM and BCAM. Due to an org change, BCAM’s are becoming CSMs and we are doing analysis on what it takes to combine the two roles.

Both roles currently have separate health scores on the account score card. We’re going to reassign BCAMs as CSMs, so we need to:

1. Move the ‘current’ BCAM health scores into the ‘current’ CSM health score ‘bucket’, including any associated historical Timeline entries (preserving original author, created date, etc.). Can this all be done via Horizon rule (or what is the best / recommended way)?
2. Move the ‘historical’ 18-week history of the BCAM score measures over to the CSM 18-week history. Is there any Timeline associated with the 18-week history?. Can this all be done via Horizon rule (or what is the best / recommended way)?
3. Deprecate the BCAM measure on the account health scorecard. What are the implications? For example, will Gainsight automatically re-calculate all aggregate account health scores as a result?
4. What are the gotcha’s to watch out for on this?

Hi Scott,

I’ve got a question around the new dynamic JO advanced program beta canvas builder and segments.

I’ve been trying to build out a test program, and have created a test segment for myself with my own email and a test email as records in our test company (the segment is built off the company person object).

I’ve been running into difficulties trying to publish the program -- I initially got the error below. Other errors I’ve gotten include “not a valid email address”.

My guess is that it’s something to do with how the fields are mapped.

Any advice on how to proceed with running test programs internally would be greatly appreciated!

Hi Scott, could you share what are the best practices for managing contacts on a customer account, when the contact leaves the customer’s employment?

Hi Scott. When I clone an existing survey, it doesn’t seem to clone the JO program that was used to distribute the original survey. Am I doing something wrong, or are the JO programs not cloned along with the survey and my only choice is to recreate it from scratch?

Hi Scott,

We’ve implemented a Pooled CSM model and the new Pooled CSM Team is using a shared inbox to manage all of the customer communication but Outlook does not allow the Gainsight Assist Add-in for shared inboxes. If time allows, I would love to chat about logging emails to Timeline for shared inboxes in hopes that there is another way to accomplish it.

Hey Scott - I’m running into issues again with dashboard limitations. I have a team that needs a lot of reports in one dashboard for convenience. To make their life easier, I included rich text widgets to separate the sections but that counts against me in terms of dashboard widget limitations. I added an enhancement suggestion in community that I think could be super helpful. 

Second question I might have, would calculated fields in the new program work to take the place of merges in the current query builder (ex: pulling in one or two fields, matched on SFDC or Track ID) so we don’t need to wait for the new query builder to launch in January?

Following up here on my findings thus far (will add a new reply after this weekend’s tests):

1. Programs with my personal company email address only (dayn.johnson@RF) built as a company program with a company person object in the segment have started sending (tested without the 11-hour recurrent evaluate step). When I launched the program at 2 pm Thursday with that 11 hour evaluate step to check whether it was a weekday, it wasn’t delivered until 1:20 am Friday. Without the evaluate step, it was delivered immediately.
   
   This 11-hour recurrent evaluation throws havoc on email send times if we have any evaluate steps that need to be evaluated multiple times.
   
   For reference, the audience setup I’ve got that is allowing these internal tests to send is:

   

2. I’m in the process (have scheduled to launch tomorrow morning) two programs to test the 11-hour evaluate step against my closest approximation of a conditional wait in the current JO builder. Now that I think about it… it’d probably be better to have our current conditional wait steps set up similarly to the test I’m running, since they too are evaluated every 11 hours if the wait time is greater than 24 hours.
   
   Essentially, what I’ve set up is a series of three evaluate steps in a waterfall, with the catch-all steps leading to a 24-hour wait before going to a subsequent evaluate step. After the third step, it should be a weekday, and the email should send at the time I want it sent (rather than in the middle of the night or during “quiet hours”).
   
   This looks… needlessly complicated. And the following evaluate steps (will have similar logic if we’re sending to folks in the EMEAs and APJ so there is an appropriate delay for those regions) will only add to the mess. And all of this to be able to use a segment to send emails, when multiple queries (scheduled to run at a specific time) could do the same thing so much easier (and do so currently).
    

   

Again, I’ll add a reply with how this weekend’s tests perform -- but if this is what the start of every program looks like, just to get to the first email, it’s highly likely we won’t send any emails through the new dynamic program builder until we’re able to schedule multiple queries in the audience that run at a particular time and only on specific days.

Did some testing this weekend -- happy to join again to chat through some of this if there’s time and interest, I’ve discovered a few things:

• Daylight savings time (when it transitions to Standard time) DEFINITELY affects when an email is delivered. I tested one program with a 24-hour wait in between day of the week evaluation steps that I launched at 7:30 on Saturday, and it was delivered at 6:30 am on Monday (so the wait timer counted 24 hours over Saturday night, and when the time rolled over Sunday morning it sent an hour early).
• Delay steps wait the same amount of time if they are 24-hour or 1-day (unless the above is true), as I tested two programs at the same time with those different interval criteria yesterday (checking that the day was equal to Tuesday), and they were delivered at the same time today. I was concerned the system may count the day earlier, rather than using the amount of time the participant had been in the journey. Based on that (and the daylight savings issue), I’ll be more likely to go with “days” in wait steps.
• The most concise way I’ve found to build a weekday check is below -- which really makes me wish we could save these sorts of logical evaluation setups, rather than having to rebuild them every time.
• I made a post on circular logic here, but it would be awesome if we could add circular logic (bringing the bottom connection back up to the top of connection so a participant could flow back through particular part of a journey if they needed to be re-routed through the evaluate steps, as opposed to having to further complicate the program).

Also -- on the calculated fields -- I’ve been pulling the “Day of the Week” from a different object in via a calculated field and dropping it in the emails as a token (successfully). Not sure whether more complex situations will work, but will definitely test it.