Variant Email Templates In Email Assist

hello @cjonas03 

This will be applicable only for NXT and NXT with salesforce connector.

This is great news! This feature will save our team from manually finding the right localized template to use. Does anyone know have an updated timeline on when this will be released?

@ashleyyoung this is what you need

Hello All,
we have this in our near term roadmap. Tentative ETA is Q1 2022.

Is there any update when this could be completed?

Any update on this? The feature has a big impact on being able to scale our team’s work. 

Any updates?  How are other companies handling this in Europe as they utilize Gainsight?

Hi All,

With July release , Multi-Version support would be available in ‘Send Email’ option in Cockpit for NxT customers.

This means CSMs can choose any version of an email template while sending email through the ‘Send Email’ option in Cockpit.

Note:

Selection of email version is not currently supported in Playbooks (as Email Tasks) & Gainsight Assist plugins.

However we plan to remove these gaps in future release(s). 

@monica 

Hi @ssamarth,

This is a great step forward! “Selection of email version is not currently supported in Playbooks (as Email Tasks) & Gainsight Assist plugins.

However we plan to remove these gaps in future release(s).” → Any timeframe planned for this? Playbooks and Email Tasks are leveraged heavily in our org and would make a huge impact on CSMs’ daily work.

Variants not being available through Playbooks and Gainsight Assist plugins is a very big gap indeed. There are exactly the main use cases I was hoping to use this new functionality for.

@ssamarth Any idea when we could expect this?

Another upvote for email variants to be available in playbooks. I don’t want to have to create another playbook/action for each variant I want to send.

Hello - we also see email variants within playbooks as an important area of this issue. Our CSMs manage accounts in multiple languages, and currently the playbook templates aren’t useful for accounts that aren’t English speaking.

Template versions will be available in Pluggins with Jan release.

@monica could update on playbook availability.

Hi there, any updates on the availability of email template version availability in Playbooks? Not being able to use versions throughout Gainsight email features is pretty inconvenient for us.

@ssamarth can you please give us an update on when will the email template version be available in Playbooks? This is a much needed feature - game chnager for our international CSMs

Looping the playbook PM @monica  

I thought I was dealing with a bug until I came across this thread. Wow, it has been out for 5+ years! Upvoting for playbook tasks picking email versions. 

Hello Gainsight team! Checking in to see if there is a timeframe of when this feature will be fully implemented. 
We support a global team and have a lot of translated email templates. It creates a good deal of unnecessary bulk within Playbooks as well as large volumes of maintenance for the admin team. 

Thanks!

Hi @linny75 ,

This is on the roadmap and we will be picking this up soon. I will keep this thread updated on the progress of the project.

Thanks,

Monica

Great, thank you Monica!

Can you share what the current status of “Parked” means?  Thanks so much!

Hey Gainsight,

We’re in the process of overhauling our email templates just now, and as part of our “engage the customer on their terms” initiative, our CSMs are translating email content for their region/language.

The thought was that, each email template would contain a version for each language and, if used in a playbook the CSM would then choose the template variant before previewing and sending to the customer.  I now understand this isn’t possible; email versions can be identified in JO via criteria, and a CSM can select the email template version required when sending an ad-hoc email, but not if the template is used as an email template as part of a playbook.

I ask myself ok, so this isn’t possible, what are the options? 

1. The language needs to be defined in the CTA rule; requiring multiple email templates, multiple playbooks and multiple rule actions.
2. The playbook task must be a task only (not an email task), requiring the CSM to send an ad-hoc email, and selecting the correct email version before previewing and sending.

Option 1 is horrible from an admin perspective; it requires the number of email templates to increase by a factor of n, where n is the number of languages templates have translations for, the same for playbooks and rule actions.  Email template and playbook assets become more burdensome to manage given their volume, and rules (I assume) take longer to process give the factor of n rule actions added to identify which language playbook/template/CTA version would need to be created.  Additionally, what happens when an additional language is supported? Instead of adding a version to each existing email template, a new template, playbook and rule action would need to be created.  Total madness.

Option 2 is horrible from the perspective of the CSM; if the majority of customers (and therefore customer communications) are in English, having CSMs read the CS Task, then have to manually add an ad-hoc email to the playbook, etc, etc is a bad experience for end-users.

Even a halfway solution (playbooks/CTA rule actions distinguishing between English/non-English) isn’t palatable for the admin experience, and would still provide a poor experience for end-users where English isn’t the primary language in their territory.

If email versions are supported in JO and ad-hoc emails, 1000% they should be supported in playbook tasks.  Am I understanding this wrongly?  If the need for email versioning was large enough for Gainsight to develop and release for JO and ad-hoc emails, surely a 360 solution should be developed so email versioning can be adopted throughout the whole product?

@ssamarth @mpatra

#productparity

Woah @Stuart, it’s like you read my mind. @kim_stone, curious to hear your perspective here, especially as we’re trying to implement multiple languages for versioning. Sounds like there’s a pretty big gap in #productparity that still needs to be fixed. 😔

I have been exactly where @Stuart is describing (1) and to say it was a frustrating and cumbersome experience is an understatement.

In my previous org we had a team of translators, if that can give you the idea of how many languages we managed...17, IIRC, including Cyrillic alphabets. This was an absolute pain, as we had to clone each playbook just to be able to have an email task to attach a template in the intended language. Plus, branching all rules to filter by each language.

So, let me do the math:
Instead of 1 template with 17 versions + 1 playbook + 1 CTA, we had 17 templates instead of one (imagine “Template xxx [EN]”,“Template xxx [PT]”, “Template xxx [GR]”, etc) plus 17 playbooks “Playbook xxx [EN]”,“Playbook xxx [PT]”, “Playbook xxx [GR]”...) where we had to update the email task to grab the correct template and then a rule with 17 branches filtered by an attribute with the Person’s preferred language plus updating each action to select the correct playbook.

It’s not pretty. Nor efficient.