Question

Best Practice for Gainsight CS CTAs when assigned owner is out of office

  • 30 April 2024
  • 7 replies
  • 67 views
security_lion
Rank
Userlevel 2

Hey folks, I am not a Gainsight CS admin so excuse my poor use of terminology.

 

We have a process in which a Gainsight CTA is created. Employee Jellybean is the assigned owner of the CTA. However, Jellybean needs to go out of office.

It’s my understanding that Gainsight CS has a limitation of only being able to assign 1 owner per CTA. I also believe there is no “out of office” rule that can be triggerred.

 

How do you all handle the situation in which an assigned owner goes out of office but the rest of the team needs to pick up their CTAs? Ideally the solution would be automated and provide the new team member with notification to take action.

7 replies

dayn.johnson
Rank
Userlevel 5
Badge +4

Following for ideas here -- this has been an issue for us, both in cases of short and long-term OoO.

CTAs are one aspect, another issue is when OoO coincides with scheduling JOs that are sent on behalf of the CSM. Being able to change up the covering CSM or include an OoO signature would be ideal for those emails.

Pooled CSM model makes the most sense for us, but curious what others have done!

"All knowledge is connected to all other knowledge. The fun is in making the connections." – Arthur C. Aufderheide
matthew_lind
Rank
Userlevel 7
Badge +10

I typically recommend one of two solutions here, the first being a process solution and the other a technical solution.

The process solution: CSMs have a backup buddy to monitor CTAs or the first-level CSM Manager monitors does so. In this case, the CTA Owner typically doesn’t change, and others cover using Cockpit Views tuned to surface CTAs of those they are covering.

The technical solution is to write a rule which reassigns all open CTAs, and any newly generated CTAs, from one user to another. I like this less because I think it’s easy for CTAs to almost literally get lost in the shuffle, and it emphasizes your company’s internal processes rather than your customer’s need.

Making people their best....currently disguised as a CS Ops Architect. How can I contribute to your success?
security_lion
Rank
Userlevel 2

@dayn.johnson Glad I’m not the only one 😄 we have a back-up buddy at the moment but the CTAs are not being reassigned to them, they have to manually check their peer’s CTAs.

@matthew_lind thanks for sharing these ideas. I’m a newbie to CS and would like to confirm the following,

  • The process solution: am I correct that this method would require the backup buddy to have a license or specific permission to do this? 
  • The technical solution: can the rule be written for a specific time frame? Is it relatively easy to create this rule? Can you expand on what you mean by the emphasis on the internal process? The way I’m reading the suggestion, both solutions focus on the workaround being internal.

Thanks so much!

matthew_lind
Rank
Userlevel 7
Badge +10

 

@matthew_lind thanks for sharing these ideas. I’m a newbie to CS and would like to confirm the following,

  • The process solution: am I correct that this method would require the backup buddy to have a license or specific permission to do this? 

 

Indeed, the backup is going to need a Gainsight license to view and action any reassigned CTAs.

  • The technical solution: can the rule be written for a specific time frame? Is it relatively easy to create this rule? Can you expand on what you mean by the emphasis on the internal process? The way I’m reading the suggestion, both solutions focus on the workaround being internal.

Ultimately, a CTA represents some element of the customer journey where you want to intervene with the customer, to mitigate risk or to capitalize on an opportunity. While I believe that CTAs need a clear owner, I also simultaneously believe that investing heavily in re-assigning CTAs during a OOO event can detract from the customer’s needs. That time and bandwidth on reassignment, especially for temporary OOO’s, focuses on internal record-keeping rather than external customer success. 

Put another way, the most successful CS teams are those who say, “As a team, we all support our customers’ journeys, and we team up for each other in a coordinated way when necessary” rather than those who say, “I’ll work only what’s in my name and not worry about anything else.”

Therefore, I’m more likely to get behind this strategy, where Bob and Shiela look out for Sunyan’s customers (ie, the CTAs for those customers) while Sunyan is OOO, triaging and prioritizing urgent items, and leaving less time-sensitive items to Sunyan upon their return. To help Bob and Shiela, I’ll help them build Cockpit views so they can see CTAs belonging to themselves and also to Sunyan.

If you elect to reassign, you have to define what should be reassigned (everything, or just new) for what time frame (when is Sunyan’s vacation again) and what should be re-reassigned upon Sunyan’s return (did I get all the CTAs back, or did some slip between cracks with all the shuffling). You could do this; I just think it’s energy that’s potentially lost developing other more externally-impactful solutions.

Making people their best....currently disguised as a CS Ops Architect. How can I contribute to your success?
dayn.johnson
Rank
Userlevel 5
Badge +4

@security_lion I’d lean towards marking @matthew_lind’s answer above as the best answer here.

@kstim, flagging this for your awareness -- is this something we’re currently doing, or that we could do? I think a combination of what’s spelled out here could work well for our team:

  1. Using a modified pooled CSM approach where we have a group email alias referenced in OoO messages so responses get picked up and covered appropriately while individuals are on vacation or on short-term PTO. For longer-term PTO (family/military/medical) it may make more sense to re-assign those accounts in Salesforce to ensure nothing gets dropped -- especially since in a lot of cases, those individuals don’t necessarily pick up everything as it was prior to their leave, at least immediately.
  2. Regarding CTAs, I really ​​​​​@matthew_lind’s suggestion of getting cockpit views created so individuals covering accounts can see those additional CTAs as needed. Is that something that could be templatized or built into a dashboard? 🤔
"All knowledge is connected to all other knowledge. The fun is in making the connections." – Arthur C. Aufderheide
Stuart
Rank
Userlevel 3
Badge +3

Hi folks, some really interesting thought points here in this thread, thanks for sharing!  Here are some of my thoughts on the subject:

 

For CTAs with short-term OoO, a buddy/leader watching over is the option that we use - CSMs can make a new Cockpit view to have sight of their colleague’s CTAs.  The downside is adding to the workload a CSM already has.  We’re also aligned that longer-term absences (all of the above + attrition) would be a reassignment in Salesforce, syncing back to GS so any new CTAs are assigned correctly, and a mass edit to move any open CTAs to the new account owner.

 

JOs cause slightly more issue; longer term isn’t so bad as for multi-step programs we use a calculated field to confirm who the current CSM is - if it’s changed in SFDC this will come from the correct person.  Short term OoO is where the difficulties lie.  If a CSM is out, the current process of using a calculated field still brings them in as the email sender.  If the customer replies, they then get an immediate OoO auto-reply back from outlook.  From the customer perspective, it’s weird and degrades trust that emails from their CSM are actually from the CSM and not auto-generated (see post on my thoughts here).

 

My initial thought would be to have some sort of field a CSM (or Admin) can change if the user is OoO, and changed back when they return (only admins can change user level fields, so the onus then gets put on the admin to keep the information correct - scalability issues?). For a multi-step program with an email send we’d need a calculated field to evaluate:
 

  • Current CSM
  • Are they OoO
    • no, send from current CSM
    • yes, send from listed manager/buddy

Sending from the listed manager would also mean having additional email versions that would say “X is out for a couple of days, in their absence though I just wanted to check in with you to talk about ABC”.  It would probably then need to check if the manager is OoO too, in that case, what do we do, send from the team mailbox, or is there a way to hold comms until the OoO is turned off?

dayn.johnson
Rank
Userlevel 5
Badge +4

JOs cause slightly more issue; longer term isn’t so bad as for multi-step programs we use a calculated field to confirm who the current CSM is - if it’s changed in SFDC this will come from the correct person.  Short term OoO is where the difficulties lie.  If a CSM is out, the current process of using a calculated field still brings them in as the email sender.  If the customer replies, they then get an immediate OoO auto-reply back from outlook.  From the customer perspective, it’s weird and degrades trust that emails from their CSM are actually from the CSM and not auto-generated (see post on my thoughts here).

 

My initial thought would be to have some sort of field a CSM (or Admin) can change if the user is OoO, and changed back when they return (only admins can change user level fields, so the onus then gets put on the admin to keep the information correct - scalability issues?). For a multi-step program with an email send we’d need a calculated field to evaluate:
 

  • Current CSM
  • Are they OoO
    • no, send from current CSM
    • yes, send from listed manager/buddy

Sending from the listed manager would also mean having additional email versions that would say “X is out for a couple of days, in their absence though I just wanted to check in with you to talk about ABC”.  It would probably then need to check if the manager is OoO too, in that case, what do we do, send from the team mailbox, or is there a way to hold comms until the OoO is turned off?

 

Yep, this (short-term out of office for JOs) is the issue we have the most here, CTAs are less of an issue. We also use the calculated field to bring CSMs in on our automated programs, but yes, it doesn’t look good, and I’m definitely in agreement with your thoughts in the linked post.

For our monthly check-in emails we send manually on behalf of our CSMs, we’ve been (so far) updating the query each time to exclude individuals who may be OoO the day/week we’re sending, but that’s absolutely not scaleable (and we’re exponentially increasing the number of CSMs in the program, so we can’t keep going that way). Our CSM leadership has proposed adding a disclaimer (to that email) that the email was sent on that CSM’s behalf, and if they need to reach someone, including a message with how to get ahold of someone -- but that doesn’t work for all of the recurring JOs we have that include the CSMs, whether in the reply-to or as the sender. Not a good look to include disclaimer in every single email that says “our CSM may be OoO”.

Ooooh. Thinking about it, this would be an AWESOME use case for dynamic content.

Using your idea above with the “OoO field”, and included a “Apologies, {CSM Name} is currently unavailable. Please contact {Covering CSM Name} or {CSM group email} if you need a faster response.” block if they were OoO. That would bypass the need for additional versions -- and some of our emails already have EIGHT versions just in the regular HTML version… and that’s before we do a defanged template and a Japanese translation...

"All knowledge is connected to all other knowledge. The fun is in making the connections." – Arthur C. Aufderheide

Reply


Terms & ConditionsCookie settings