Customer user cases

Hi @stefanoboni, welcome to the Community!

Hope I understood the workflow correctly, but let’s say that you send a first survey to collect the use cases (eg, a multi picklist field) and from that data, you want to send different surveys out instead of one with a conditional branching logic. If you have the contact identified, you can achieve the next step via Journey Orchestrator, using as source the flattened object from the first survey. Alternatively (same source object) you can trigger a CTA via rules engine leveraging email tasks.

Whatever path you choose, each survey will be visible in C360. And if you need to re-feed the data from he survey as a field in Company to surface it in C360, you can do that via rules engine too.

Please let me know if this helps or if I didn’t understand what you were looking for

Hi @romihache ,

thank you for the answer! What I’m looking for it’s slightly different. When we do PoC/potential uses cases for customers the first thing we do it’s collect some information from them that we think are relevant (the word document I was mentioning before).

I’m trying to do the same in Gainsight, but it should be very punctual and standardized.

Possible scenario: I have a prospect who wants to do a PoC with our platform. I send out a standardized survey (just to that Prospect) to gather the information needed to create the PoC, and then store it in Gainsight. Two months later, the prospect has a new use case, so I send the same standardized survey (again, just to that prospect) to collect the new information. In Gainsight, I need to be able to see both the initial PoC survey they filled out and the subsequent use case survey.

Thank you so much!

For context, the screenshot above was me testing a survey sent via a CTA task. Same survey, same contact (myself).

You can test it by yourself, the email stats will match each of the emails sent. It’s practically real-time data so it’s easy to validate it.

 

That’s exactly what I was looking for, thanks so much @romihache!

In order to send the survey from a CTA you just need to apply the template to an email task in a playbook, correct?

Thanks again! 

Yup, that’s it!
Happy to help 😊

Hope I got it right this time @stefanoboni  😅

Even if you send the same survey multiple times to the same contact, each of them gets a unique URL/GSID:
 

 

Wow, glad I’m following new posts, @romihache -- this is fantastic. I’ve got surveys on my “need to explore” list, and this is a fantastic use case for us, particularly the bit about how the survey responses are visible in C360. And thanks for sharing that link about the flattened survey object -- I’d seen that referenced frequently in the #JO channel, and it makes perfect sense in this context!

Just in case, @dayn.johnson. A TIL quirk regarding the preview (well, actually was on Friday PM, learned this thanks to a question responded by Alizée via quickhelp) is that if any of the questions has a tokenized value the preview will resolve the token “on demand”.

I noticed that in C360, all surveys are listed with the same name (the template name). Is there any way to change this? My idea is to use the same survey templates for different use cases, so ideally, they would appear in C360 with the name of the use cases instead of the template name

Thank you so much!

Nop, you can’t change that @stefanoboni . What you can potentially do if your use cases are known/limited is to clone the original template and rename each one based on the use case to send accordingly.

This seems like (yet another) great reason to have tags throughout the platform.

Use-case specific tags should make it feasible to show all surveys pertaining to the associated use-case(s).

@dayn.johnson , great idea! Tags should be added in the email template?

Not actually within the template. What I’m thinking of would be similar to the way we can tag a post in the Community, so that we would have an additional level to filter by within our various digital asset libraries (email templates, surveys, JOs, rules, reports, etc.) and didn’t have to resort to naming conventions and the (limited) folders and sub-folder hierarchies we can create -- especially since we’re only limited to one level of sub-folders, and they don’t apply to the Analyzer.