Each Model has components that can be configured to create customized Programs. The components available within a model are largely determined by if the model is designed to send surveys or if it is designed to send other messages. For a brief summary of each model, refer to Available Models for Program. For more information on adding participants to a Program, refer to Adding Participants to a Program.
Within the program model configuration screen, you can scroll to zoom in and out of the model using the mouse. You can also click and drag the model, or use the arrow keys to pan across the screen.
Survey models include the NPS® Survey, Customer Satisfaction Survey, and Generic Survey models. They each contain optional components that can be Enabled/Disabled, as well as a Conditional Wait option, that controls the amount of time that must pass before the next message in the email chain is sent based on set conditions. Some models also have a Set Timer section that controls the time interval before the next message is sent automatically. Each of these models has a Survey Settings page that controls what survey is sent as part of the outreach.
Certain emails within a model, such as the “Head’s up” and “Thank you” emails within the NPS® model, can be enabled and disabled depending on the needs of the user. To enable or disable these components, click the Yellow Diamonds in the model. Then select ON/OFF. Disabled emails are gray, and turn blue when enabled.
Conditional Wait is represented by a dark blue octagon. Clicking Conditional Wait allows a user to control how much time has to pass before a Reminder Email is sent to the recipient, or an Escalation Email is sent to the CSM, and how often these emails should be sent. The amount of time can be configured in Days, Hours, or Minutes.
Limitation: There might be a delay of 15 to 30 minutes to complete the step after the Conditional Wait step, during peak hours, due to load on email infra.
- Repeat N times: Set this to 1, if you just want to send only one reminder to the contact, or adjust based on your requirements. For example, in the below use-case, if a user wants to send the reminder emails three times after every 2 days. Set the value in the Conditional Wait After and Repeat N times fields to 2 and 3 respectively.
Note: This step is applicable to the sections, Reminder Email and Escalation Email configurations.
- Wait for N Days: This wait period is the total time you would like to wait for the user to respond to the Survey before ending his Program lifecycle. After this time has expired, the survey will still remain active, and if the customer responds or opens the survey email this will record within both the Program and the survey. We are currently planning an enhancement that will allow users to expire the link in N days after it has been sent to a participant.
Conditional Wait Example
- The first section enables configuration of reminder emails.
- The second section sets the wait time for an escalation email.
- The third section marks the end of a participant’s life cycle. After the time expires, the participant no longer will receive reminders and their participation status will be completed.
- If the first or second sections are assigned higher wait times than the third, the reminder/escalation mails do not go out.
IMPORTANT: The Reminder and Escalation emails are sent at the same time if they are configured to wait for the same number of days after the survey email is sent. Both Escalation and Reminder emails depend only on the time of the first Survey email.
For more information, see Program: Conditional Wait.
Set Timer is represented by a blue circle. Clicking the Set Timer option allows a user to control the time interval before the next email in the campaign is sent automatically. This is usually configured between a Heads Up Email and a Survey Email. The Timer begins after the heads-up email is sent.
Limitation: There might be a delay of 15 to 30 minutes to complete the step after Set Timer step, during peak hours, due to load on email infra.
This step creates a branching path based on whether or not a participant has responded to the Program. If the participant responded to the Program, they will move to the next step on the right. If they do not respond, they will move to the next step down. It is available for all Survey models and can be used with both Surveys 1.0 and 2.0.
For participants that have responded, you can add the steps Conditional Wait, Wait Timer, Send Email, Create CTA, and End Outreach. A common use case for this feature is to send a thank you email with a delay timer.
- Conditional Wait: This step is branching and offers additional steps depending on if a participant meets the configured conditions. The Conditional Wait step added here is configured differently than the default Conditional Wait step included in survey models. Refer to Programs: Conditional Wait for more information on how to configure this step.
Note: Adding the Conditional Wait step after the Responded Step in a survey model gives you the option to include survey answers (from Survey 2.0 only) as conditions. With this option, you can control how participants move through the Program based on their answers. For example, you could choose to create a CTA based on an NPS® detractor response. Refer to Survey Questions section of the article Programs: Conditional Wait for more information on how to configure this option.
- Wait Timer: Refer to Set Timer for more information on how to configure this step. You have the option to add a Send Email, Create CTA, and Conditional Wait step immediately after the timer. Additional steps beyond that will vary depending on what is added.
- Send Email: Refer to Configure Emails for more information on this step. You have the option to add a Conditional Wait, Wait Timer, or End Outreach step immediately after the email step. Additional steps beyond that will vary depending on what is added.
- Create CTA: These steps operate similarly to the ability to create and close CTAs within the Rules Engine. For example, the create CTA step requires Type, Status, Reason, Due Date, Priority and Default Owner to be filled out. For more information regarding configuring each step of the CTA, refer to Creating and Closing CTAs from Rules Engine. You have the option to add a Wait Timer, Conditional Wait, or End Outreach step after this one. Additional steps beyond that will vary depending on what is added.
- End Outreach: Participants passing through the End Outreach step will be moved to completed. There is nothing to configure with this step.
Note: When a Survey response is deleted, relevant JO entries are deleted and the participants are dropped from the journey in order to ensure accurate Survey and Program Analytics statistics. It also removes participants from the participant grid view, participant activities, email logs, email events, and mapping of CTA to that participant. This not only affects the participants of an Active program, but also Paused programs.
Not Responded Options
For participants that have not responded, you can add the steps Send Email, Create CTA, and End Outreach. This option is designed for silent accounts, where you sent reminder and escalation emails and have not received a response.
- Send Email: Refer to Configure Emails for more information on this step. You will have the option to add a End Outreach step after this one.
- Create CTA: These steps operate similarly to the ability to create and close CTAs within the Rules Engine. For example, the create CTA step requires Type, Status, Reason, Due Date, Priority and Default Owner to be filled out. For more information regarding configuring each step of the CTA, refer to Creating and Closing CTAs from Rules Engine. You will have the option to add a End Outreach step after this one.
End Outreach: Participants passing through the End Outreach step will be moved to completed. There is nothing to configure with this step.
Email Chain Model
The Email Chain Model is designed to send a series of related email outreaches, such as messages related to the Onboarding Process. The model starts with a Participant component and an initial Email component. Additional components can be added by clicking the plus icon. Wait Timer and Conditional Wait steps must be added between action steps such as Send Email or Create/Close CTA. You can delete any step you’ve added by hovering over the step’s icon and clicking the trash can icon. It is not possible to delete a step without first deleting any steps that come after it in the chain. Email templates containing surveys can not be used with this model.
Limitation: To view the program email model correctly in the browser, Admins must set the browser zoom settings to 100%.
Admins have the ability to create and close multiple CTAs as part of the Program journey. The create and close CTA steps can be added by clicking the + icon after a Wait Timer or Conditional Wait step.
These steps operate similarly to the ability to create and close CTAs within the Rules Engine. For example, the create CTA step requires Type, Status, Reason, Due Date, Priority and Default Owner to be filled out. For more information regarding configuring each step of the CTA, refer to Creating and Closing CTAs from Rules Engine.
Note: Since Admins cannot add ID fields in the Journey Orchestrator Custom fields, only standard participant ID fields are allowed to map in the Owner Field while creating a CTA in Journey Orchestrator.
When configuring the Create/Close CTA steps, Admins can add Survey Fields and Calculated Fields as tokens. For more information on using Survey Fields and Calculated Fields, refer to Programs: Using Survey Fields and Programs: Using Calculated Fields.
Note: The Associated Contact field can only be populated with the Participant’s SFDC Contact ID. This will associate the CTA with the participant when it is created. We recommend adding this association for reporting purposes.
In the case of native field mappings, the Program will resolve standard GS fields to the respective SFDC fields and will try to create a CTA. If CTA name is not included as an identifier and more than one open CTA are found for the same Account Id, Reason, and Type at Cockpit, then the participant with only one CTA will be associated randomly.
After a CTA is created through a Program, users can access the participant’s journey from the CTA detail view in Cockpit.
This will bring up a pop-up window with a list of all participants associated with the CTA. It is possible that participants from multiple Programs can be associated with one CTA. The list displays the Participant Name, Email Address, Program Name, and Participant State. You can also click View Activity to see the participant’s activity in more detail. For more information on the Activity Feed, refer to Program: Activity Feed.
The close CTA step requires users to select which CTA step in the Program they would like to close, and what status they would like to set the CTA to. Users can also add comments and select if they would like to post an update to chatter. This feature is meant to automate the closure of CTAs if certain conditions in the Program are met, so that manual interaction with the CTA is only needed if those conditions are not met.
You can correct or update the contents of CTA steps even after the program has been published. Any changes made will be applied to new participants and existing participants that have yet to pass through those steps.
Note: Program CTA actions will not work with dummy accounts. The CTA steps are designed for customers only. Participants associated with dummy accounts will be dropped if they reach a CTA step.
The action type ‘Call API’ in Programs is used to integrate with the external callout framework and list all the connections used by the user. This action type is supported for all model types in Journey Orchestrator. Admins can select an external connector and its respective actions, and also select the participant fields and tokens to be populated for the dynamic token fields from external callout.
Admins can add the Call API step by clicking + after a Wait Timer or Conditional Wait step.
For more information on Call External API action type, refer to Call API Action Type in Programs.
Trigger PX Engagements
Gainsight integrates Journey Orchestrator (JO) with PX. You can trigger PX in-app engagements from Programs, take action based on the engagement events in Programs, and analyze and measure Program and Engagement effectiveness. This integration helps customers achieve a unified customer engagement strategy by leveraging the best of both JO and PX applications.
- Dialog, Slider, and Guide PX in-app engagements can be triggered in all Program model types.
- Survey PX in-app engagements cannot be triggered in the Email Chain program model.
By default, this feature is enabled for all the customers who have CS and PX subscriptions.
Business Use Cases
Following are some of the business use cases for the JO+PX integration feature:
- While On-boarding a new customer, Admins can send a ‘Welcome Email’ with a walkthrough of the CS application using PX engagement.
- After a new release, Admins can trigger a PX engagement, from Program, which consists of a release video to all users.
CS admin wants to send an in-app NPS® survey and if not responded then wants to send an email reminder.
Support team wants to send an in-app CSAT survey after the support ticket is closed.
The following are the prerequisites to use this feature:
- Customers must have subscriptions for both the Gainsight Journey Orchestrator module in the CS application and also the Gainsight PX application.
- Configure the PX Connector in the Gainsight CS application. For more information, refer to Gainsight PX Connector.
For more information, refer to Journey Orchestrator and PX Integration.
The Wait Timer step can be configured to wait a set amount of Days, Hours, or minutes before sending the next message.
The Conditional Wait looks for a set condition to be met before sending the next message. These conditions include Event-Based Conditions, Calculated Field-Based Conditions, Event Field-Based Conditions, and Participant Field-Based Conditions.
For more information on Conditional Wait Enhancements, refer to Program: Conditional Wait.
Users can configure the Email Chain model to progress non-linearly. The Conditional Wait feature can be configured to split the model into multiple pathways depending on whether the participant meets the conditions configured.
When Participants meet the conditions of the Conditional Wait, they will proceed to the model step directly to the right of the Conditional Wait step.
Participants who do not meet the conditions of the Conditional Wait will proceed to the step directly below the Conditional Wait step. This can be configured with the following options: Send Email, Create CTA, Close CTA, Continue, or End Outreach.
Selecting Send Email, Create CTA, or Close CTA for this branch of the Conditional Wait step provides Admins with the additional options for participants to Continue or End Outreach.
Participants passing through a Continue step moves to step two to the right of the Conditional Wait step. Participants cannot move to the step immediately after Conditional Wait, as they did not meet the conditions configured within the Conditional Wait step. This is designed to allow Participants to continue moving through the Program journey while skipping steps for which they did not meet the conditions. In the below use-case, a participant moving through a Continue step after the Close CTA step will then move to the second Conditional Wait step.
However, if the Wait Timer step is added after the Conditional Wait step, the Participants passing through a Continue step moves to Wait Timer step (immediate step to the right of the Conditional Wait step). It is an expected behavior of the Program functionality. In the below use-case, a participant moving through a Continue step after the Close CTA step will then move to the Set Timer step.
Note: Participants passing through the End Outreach step are moved to completed.
Email templates that are marked as operational can be included in the Email Chain model. No other models can be used for Operational Emails. For more information on Operational Emails, refer to Operational Email Guidelines. For more information on marking email templates as operational, refer to Create Journey Orchestrator Email Templates.
An Operational email can be included in any email step in the Email Chain Model. You can add a combination of operational and non-operational email steps.
Note: If a combination of Operational and Non-Operational Email templates are used in a program, the participants will be dropped from the program if they are in opt-out list even though an Operational Email template is used in it.
Users can add the cc list to the email by selecting the CC checkbox, which can only be enabled when sending Operational Emails in JO. Currently, only 3 email recipients can be added to the cc list.
Users can also track individual email events, such as open, click, and others, for ‘to’ and ‘cc’ emails in Email Logs and Program emails.
If a combination of operational and non-operational email templates are used in the program, the participants would get dropped from the program if they are in opt-out list even though an Operational email template is used in it.
The analytics report is only generated on ‘To’ emails and not yet supported on ‘CC’ emails.
Note: If a CCed email participant responds to a Survey, the system considers this as an actual participant response and the journey moves ahead for that particular participant. If ‘Thank you Email’ is configured, it is sent to the actual (To) participant.
For a Program which has at least one operational email template, the following restrictions apply:
- No more than 5000 (or the limit configured per tenant) active participants can be within the Program. If more than 5000 participants are added, the participants will be dropped.
- No more than 5000 participants can be added to the Program per day.
Example: If you add 5000 participants to a Program the first day it is published, and then 1000 of those participants move to completed or are dropped from the outreach in that same day, you will not be able to add more participants until the next day even though there are less than 5000 participants currently active.
After an operational email template is added to an email configuration step of a Program, the following message will be displayed informing the user they have selected an operational template:
Each Program model can contain multiple email template placeholders; however, not all of these emails are included in every model:
- Survey Email: This email should contain the survey placeholder.
- Heads Up Email: This should be configured to let the customer know ahead of time that a survey email will be sent to them in the near future. Sending a Heads Up Email has proven to increase a survey's response rate.
- Reminder Email: This email should be configured and sent to remind users who have not responded, or only partially responded/saved the survey, to complete the survey.
Note: if a Survey is configured to move someone to Partial Submitted before the Conditional Wait would send the reminder email, then the reminder email will NOT be sent to them.
- Escalation Email: This email should be configured to send to the account's CSM, or another role managing the customer's account. The purpose of this email is to let the account owner know that the customer has not completed the survey, and to suggest next steps.
- Thank You Email: This email should be configured to express gratitude to customers that have responded to the survey.
- Send Email: These email components are part of an Email Chain and should be configured to contain whatever information is needed in that stage of the chain.
To configure each email within the model, click the email element. The email configuration screen will then display full screen.
Users have the option to configure the following:
- To: address of the email
- From Name: of the email
- From Email: displayed within the message
- Reply-To: address of the email
- Email Copy: select an email address to send a copy of the email to
- Template: of the email’s content (must be Email Template 2.0). Program emails can use templates configured to attach reports either inline or CSV. For more information on creating email templates and sending emails with attached reports refer to Create Journey Orchestrator Email Templates and Programs: Sharing Reports. Multi-Version email templates are supported for Programs.
- Log to Timeline: If this checkbox is selected, the emails triggered from this program are logged as Activities in Timeline. All the emails sent from a program for a company/relationship on a particular day are logged as one Activity. The Activity Type is set to Automated Program by default. For more information refer to the Access Automated Program Activities article.
Custom email fields can be selected for the fields “To”, “Reply-to”, “From Email”, and “Email Copy to”. For more information on custom email fields, refer to Adding Participants to a Program.
After configuring the email, users have the following options at the top-right of the email configuration screen:
- Save: Save the configurations you've made to the email
- Discard Changes: Revert the email configuration back to its last saved version
- Back to Model: Navigate back to the model configuration page
- Preview: Preview the configured email. For more information on previewing emails as part of a Program, refer to How to Test a Program.
Note: After a link to a survey is established within a Program, it can not be changed to a different survey within the email configuration page. To change the survey, click the pencil icon to edit the details of the Program.
After the email template is selected, users have the option to map any included tokens and to link to any selected surveys. Admins can use Survey Fields and Calculated Fields as tokenization options. For more information on using Survey Fields and Calculated Fields refer to Programs: Using Survey Fields and Programs: Using Calculated Fields.
For all Program models, users can access the Snapshot mode to view the number of participants that are currently in each stage of a published Program. Click the camera icon in the top-right of the outreach model page to access the Snapshot.
This Snapshot will appear identical to the outreach model with the number of participants that have passed through each step displayed next to it. Users can click the number of participants to view the list of participants that have passed through that step of the program. This view of participants is similar to the Participant Activity view in the Activity Feed.
The Program Snapshot view has an “in process” state to show when participants are between program steps. It is normal for Participants to spend time “in process” as background jobs related to the program take time to complete. The icon for “in process” participants will display between the Program’s steps in the Snapshot view. You can click the “in process” icon to view the list of Participants currently being processed at that point in the program journey.
In the Snapshot mode, Admins can’t configure the model steps. Click Exit Snapshot Mode to return to the model configuration page.
The Snapshot view will not fetch the data for participant lists view if the number of participants exceeds 99999.
Troubleshooting Configuration Errors
The model configuration screen will highlight steps that have not been configured properly after the Admin clicks PUBLISH on a Program. This is available for all Program models.
When users click the PUBLISH button, red highlights will appear over any steps within the model that have not been configured properly and would prevent the outreach from being published successfully. If this feature identifies one or more steps that have not been properly configured, the outreach will not be published.
Users can hover over the red exclamation points at the top-right of any highlighted step for more information on the configuration issue.
After users have resolved the configuration issues, they can click PUBLISH again to complete publishing the Program.
Publishing and Exiting the Model
After configuring the Program, users have three options before exiting the model:
Save: This saves any configuration changes made to the model.
Discard Changes: This exits the model without saving any configurations that have been made.
Publish: This publishes the outreach and begins the process of sending messages to participants. After clicking PUBLISH, a pop-up window will display asking if you would like to proceed with publishing the program. Admins have the option to publish the Program immediately or schedule it to publish at a later time.
- Note: Once the Program is Published and Active, you are limited in your ability to configure it further. You can make the following edits:
- Generate a query to pull in participants
- Modify the schedule for when the query runs
- Configure Uniqueness Criteria
- Remove Participants
- Modify Email Templates (edits will be reflected for participants going forward)
- Modify any CTA steps (edits will be reflected for participants going forward)
For more information on these available configurations, refer to Adding Participants to a Program.
You can select to publish the program now, placing the program in an Active status, and possibly triggering any initial program emails.
You can select to schedule the program to publish at a later time. Choosing to schedule at a later time gives you more control of when the Program starts sending messages and does not require you to manually complete publishing. After selecting this option you will be able to select the date and time to publish the program.
IMPORTANT: In order for a scheduled participant sync to occur, a program must either be active or have a scheduled publish date at the Program level. If you plan to publish programs on a delayed schedule, we recommend activating the program first from the program model screen and then schedule a date and time for the program to be published.
After selecting a date and time, click YES to complete scheduling the program. Programs that are scheduled to publish have a status of SCHEDULED. At the scheduled date and time, the program will move to Active status as part of the publishing process.
After a program is scheduled, a message will display on the top right of the Program model configuration identifying when the Program is scheduled to go live. You can click the pencil icon to edit the date and time of the publish schedule.
Admins can remove a program’s scheduled publish entirely. In the model configuration screen, you can click on the status drop-down to edit the Program from SCHEDULED to DRAFT. This will remove the publish schedule.
You can view scheduled programs alongside scheduled outreaches and refresh schedules for program sources in the Program calendar view. For more information on this view, refer to Program List View and Create New Program.
Automatic Validation of a Published Program
Gainsight runs a Validation process, in the backend, to validate all the configurations of a program, once the program is published. If there are any errors, it sends out an email notification to the user who published the program. Therefore, the status of the program is changed from ACTIVE to DRAFT and also the participant’s state is changed from NEW to REVIEW.
Note: Validation service is applicable only for Published programs.
An email notification is sent to the following users in different cases:
- For Manual Execution - Email notification is sent to Logged in user or the user who is publishing the program.
- For Scheduled Execution - Email notification is sent to the user who created the schedule.
This validation process is applicable to all program models. The following are the scenarios where validations are performed in the backend for a published Program:
- Survey/Report token validations.
- Versions exist or not.
- Configured email template exists or not.
- From and To email address exists or not.
- All the tokens in the email template mapped or not.
- Standard tokens exist in the participant mapping or not.
- The calculated fields exist in the JO configuration or not.
Note: Validation service is not supported for Call External API feature.
Options for Published Programs
After a Program has been published, the model configuration view changes to reflect new options available.
- Back to Program List: Click here to navigate to the Program List View.
- Program Status Drop-down: This drop-down will display the Program's current status. From here you can select to Pause or Stop the Program. For more information on Program statuses, refer to Program List View and Create New Outreach.
IMPORTANT: After a status change is selected, a warning message will display, explaining how the selected status change will affect the Program. Admins can then select either YES or NO to confirm or cancel the status change.
The text of the displayed message will depend on the status selected:
- Changing status to Pause: The Actions/Activities that are in queue at the time when the Program is paused are executed normally, and the participants are paused only at the next Wait Timer/Conditional wait. Once the Program is resumed, all the timers will be adjusted to account for the paused duration. For example, assume that you have a step which says Wait for 3 days, but you have paused the program for a day and then resumed it. The wait step automatically recognizes the pause duration of 1 day, and now waits for 4 days instead of 3 to compensate for the pause duration.
Note: While the program is in a paused state, Gainsight captures all the events of participants' such as Email Clicks, Close Event, CTA Open/Close for a period of 60 days after the program is paused. If the program is resumed beyond this period, the data will not be preserved. You can resume the program with the updated statuses of all participants’ activities before the pause period. Moreover, you can also resume the program from it’s original state before pausing the program.
- Changing to Stop: "Clicking YES will stop the program and the status of the participants will be changed to Completed. You will not be able to resume the program. Are you sure you want to continue?"
When the program is stopped, the participants with the status "New" and "Active" will only be changed to Knocked-Off. Rest of the participants' status will not be changed and remains same."
Stopped Programs do not allow adding new participants. You cannot setup any new configurations and the Program can not be started again. We recommend exercising caution when you change the Program status to Stop.
- User Clicks on Resume: "Clicking YES will make the program active and the participants will continue in the journey. Are you sure you want to continue?"
- Once the Program is resumed, all the timers will be offset to account for the paused duration.
- User Clicks on Draft (only available from the Scheduled status): "Clicking YES will remove the schedule and make the program to the draft state. Are you sure you want to continue?"
- Edit Program Details: Click here to edit a Program's basic details, For more information on editing Sources after Publishing a Program, refer to Add Participants to a Program.
- Program Snapshot: Click here to navigate to the Program's Snapshot mode.
- Participant Activity Feed: Click here to navigate to the Program's Participant Activity Feed.
- Program Analytics: Click here to navigate to the individual Program's analytics. Refer to Program Analytics for more information.
If you have questions or feedback about the feature explained in this article, please share them on community.gainsight.com.
|NPS, Net Promoter, and Net Promoter Score are registered trademarks of Satmetrix Systems, Inc., Bain & Company and Fred Reichheld.|