Solved

Variant Emails: Feedback (need for multi-filter variant condition + non-picklist values for timesend)

  • 22 February 2017
  • 6 replies
  • 55 views
nora_soza
Rank
Badge
Feedback

1. Requirement that the time scheduler must use a pick-list field is very limiting, and makes the functionality unusable for our org.

2.

Single attribute variant filters are limiting. Still need to create

multiple power lists to support more complex customer segmentation.



Hi Gainsight Team --



I am very excited about the variant functionality that came out this week. This was a great step forward in running well organized campaigns. We're already working on consolidating existing campaigns, and have some feedback to pass along.



When building out a new campaign, we have 3 account attributes that define the type of content a customer should receive.


  • Account metadata - for example, based on the license type we would send materials specific to what functionality is available to them.

  • Segment - Based on segment provide high touch or low-touch resources
  • Region - Determines the language and timezone
Current state (with single filter variants and dependency on time scheduler field being a picklist), With 2 segments in 3 different regions, 6 power lists need to be created, that then map to 5 templates (based on account metadata). We are using the account metadata in the filter condition for the variants.



https://support.gainsight.com/Product_Documentation/CoPilot_and_Automated_Email/User_Guides/Create_and_Send_Multi-Variant_Emails
icon

Best answer by dan_ahrens 6 March 2017, 22:41

View original

6 replies

dan_ahrens
Rank
Userlevel 7
Badge +2
Hi Nora, this is certainly a multi-faceted use case. If I'm reading this correctly you essentially have up to 30 different variants - 2 segments x 3 regions x 5 account metadata options. Is this correct?



One thought to help cut down on the number of different templates would be to create customer record level fields for data in the segment qualifier (and maybe account as well) and tokenize that data in the template, so instead of 'hard coding' the text in each template, you let the data tokens create that customization. 



Do you think that might work?
VP of Customer Success at Forcepoint
nora_soza
Rank
Badge
Hey Dan -- Thanks for the reply + workaround.  I've attached an image to show how we would use similar templates for the different regions. It brings the number of templates down to 12 (a number I can live with).



Right now, the best way I can see to reducing the number of power lists, but still hit my timing and language requirements, is to create 6 power lists with 12 templates, leveraging the Account Metadata with the variants.



Ideally, we could get this down to 1 power list, with 12 variations, and I could use complex filters to map to different variants:



ex:

If = High-Touch AND = License A AND != France then >  to HT: License A

If = High Touch AND = License A  AND != France then >  to HT: License A (French)

**Then using the time scheduler, I would stagger France and EMEA to send earlier in the morning before the non-France and EMEA.



dan_ahrens
Rank
Userlevel 7
Badge +2
Thanks for posting that flow chart, it helps to visualize. A couple thoughts here:



1 - could you create an account level field that represented the amalgam of the options and would could be used as a single field discriminator mapping to the correct variant? I'm thinking something like this: [H or L] [U, E or F] [ A, B or C] such that a Low touch, France, License B customer would show LFB in that field. Or a High touch, EMEA customer with License A would show HEA in that field. 



2 - I'm assuming that the messaging differences between license types would be significant enough that you couldn't tokenize the text, correct?
VP of Customer Success at Forcepoint
nora_soza
Rank
Badge
1 - It's an interesting thought, but would require coding from our SFDC admins. Our campaigns would now be dependent/delayed by our bi-monthly release cycle. (YAY compliance 🙂 ) Additionally, we have a number of campaigns running -- the use case above is license upgrades, but things like activity metrics, change in role, etc. are all possibilities for campaigns to be run. A piece we love about copilot is how fast we can iterate our campaigns to ensure maximum effectiveness. Adding in a dependency on a new field + coding would slow us down.



2 - Yep, complete different copy for each license. Tokenizing wouldn't work for this campaign.



Appreciate the brainstorming! We'll stick with multiple powerlists for the time being.
dan_ahrens
Rank
Userlevel 7
Badge +2
One thought on bypassing SFDC admin time is to create a table in MDA that would house these values. You could use the Gainsight rules engine to automatically populate those entries based on account criteria that exists (read only) in SFDC. 
VP of Customer Success at Forcepoint
dan_ahrens
Rank
Userlevel 7
Badge +2
Since the release of Gainsight v5.5 in late February, you can now use Bionic Rules to create complex data sets using inner and outer joins and then merge that data in memory to create aggregations or merges. 



Might be relevant to some of the considerations in this thread.



More info here: https://support.gainsight.com/Product_Documentation/Rules_Engine/Admin_Configuration/Getting_Started...
VP of Customer Success at Forcepoint

Reply


Terms & ConditionsCookie settings